From patchwork Sat Aug 26 12:53:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cristian Marussi X-Patchwork-Id: 13366588 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 67AFDC83F01 for ; Sat, 26 Aug 2023 12:54:15 +0000 (UTC) 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=Bth270LBENcvbxRy0fLpM7RCJCeSCncJN9Rf7Za8RG4=; b=Nnjqi2E+0czWfu epZAxKRmMQUWwzSN1FX61fDf/xeg4JgCpWEQ1ebPEzP8nHCzIQobMDnit8Y8L+ZgbZvXm53LWjW2a wHkPt8Crfbw6IUWWVsoLg/iZ8fSD77Oq7WM3P4bFMnTqs/aTfQUUCuGsYINXQIot5LYPd6RuQnjgE 3oDaQkZtWUE1J9nist6By7aGziuSoIAJpd5u7YzDCjS4ccSLqt7Wf6sAVIGB0Q0UNksVTWLSqfB3k 03dVJXh9+qm79Cso7VzH+IyKD+JC2s3wf0q+3Wh/QkVe01qh8va/wWnBbQlKzwyGVUynPXuCl5Upi +gKANHi/T9JDJotdlsZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qZsnU-006u6I-2W; Sat, 26 Aug 2023 12:53:48 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qZsnR-006u5h-1o for linux-arm-kernel@lists.infradead.org; Sat, 26 Aug 2023 12:53:47 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 28DB41FB; Sat, 26 Aug 2023 05:54:23 -0700 (PDT) Received: from pluto.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2BD5F3F64C; Sat, 26 Aug 2023 05:53:41 -0700 (PDT) From: Cristian Marussi To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com, f.fainelli@gmail.com, vincent.guittot@linaro.org, etienne.carriere@foss.st.com, peng.fan@oss.nxp.com, chuck.cannon@nxp.com, souvik.chakravarty@arm.com, nicola.mazzucato@arm.com, Cristian Marussi Subject: [PATCH v2 0/6] Add SCMI v3.2 Clock new CONFIGs support Date: Sat, 26 Aug 2023 13:53:02 +0100 Message-ID: <20230826125308.462328-1-cristian.marussi@arm.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230826_055345_650801_6F736906 X-CRM114-Status: GOOD ( 10.96 ) 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 all, this small series introduces support for the new Clock CONFIG features added by SCMI v3.2 specification [1]. It does NOT add support, still, for the SCMI v3.2 Clock reparenting features added in v3.2 too. After a small refactoring in [1/6], support for the new CONFIG_SET message format is added in [2/6]: this is just internal rework to support new and legacy (pre-v3.2) message formats. Patch [3/6] adds support for the new v3.2 CONFIG_GET command and adds a new related Clock operation .state_get() to retrieve the enabled state of one clock when talking to a v3.2 compliant server. Patch [4/6] extend .state_get() support to legacy SCMI platforms implementing pre-v3.2 SCMI stacks: in such a scenario we can use the old CLOCK_ATTRIBUTES command to retrieve the clock state. Patch [5/6] finally wires up this new .state_get() clock operation to the Linux Clock framework .is_enabled() callback, AS-LONG-AS the underlying configured SCMI stack supports atomic operations. (since .is_enabled() is required not to sleep) This *should* ease unused clocks management by the Linux Clock framework. Last but not least, patch [6/6] exposes a couple more SCMI Clock operations in order to be able to set/get OEM specific clock configuration values as described in SCMI v3.2 specification. Tested on JUNO and on an SCMI emulation setup. Based on v6.5-rc5. Any feedback welcome, Thanks, Cristian [1]: https://developer.arm.com/documentation/den0056/e ---- v1 --> v2 - more descriptive commit message for 1/6 - add and use more descriptive defines to name boolean arguments in clk-scmi.c - dropped RFC from 6/6 Cristian Marussi (6): firmware: arm_scmi: Simplify enable/disable Clock operations firmware: arm_scmi: Add Clock v3.2 CONFIG_SET support firmware: arm_scmi: Add v3.2 Clock CONFIG_GET support firmware: arm_scmi: Add Clock .state_get support to pre-v3.2 clk: scmi: Add support for .is_enabled clk_ops firmware: arm_scmi: Add Clock OEM config clock operations drivers/clk/clk-scmi.c | 34 ++++- drivers/firmware/arm_scmi/clock.c | 220 +++++++++++++++++++++++++++--- include/linux/scmi_protocol.h | 19 ++- 3 files changed, 243 insertions(+), 30 deletions(-)