From patchwork Fri Aug 11 16:14:40 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cristian Marussi X-Patchwork-Id: 13351087 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 71A71C001DE for ; Fri, 11 Aug 2023 16:16:24 +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=SlG5jU8bnA5mjiVCdA6UczQnAun+l46vV57Azt2IzFA=; b=FgKR5b4Miu9wTJ Tn7Xe5YHh1FetlyuFycyA0e5nYwoKOdj/t/nB0sDddJMPaChE9+60rOeFqapXTQzZY0NobB4esgbH xHSJcXw8Ot48pZiWAS5Xh+fgfR0pzH6qSDigDxNCJRWiYBOz8kUAuGA6YYbdegA8Cs2DXxdyb9Hzy gAnO8avvlPoH8M2H8GPcBm1AJF5kVluQ8KSavXTuv87s0wFKySWbR6jBgJI68KQP6+j6R0dm+rZk9 ayFwZ0RjPzgYEdqKrje5+xeJL0znUfYCf3D+rLw1Sm/BbFD0NZMwOUkH3eDZJCqXRcERFCcu0a/gk rMp3rqr7xg0pA5Eh1MWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qUUnt-00B4id-1Y; Fri, 11 Aug 2023 16:15:57 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qUUnq-00B4h0-2H for linux-arm-kernel@lists.infradead.org; Fri, 11 Aug 2023 16:15:56 +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 0D7E2113E; Fri, 11 Aug 2023 09:16:34 -0700 (PDT) Received: from pluto.. (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 68E1D3F64C; Fri, 11 Aug 2023 09:15:49 -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@linaro.org, peng.fan@oss.nxp.com, chuck.cannon@nxp.com, souvik.chakravarty@arm.com, nicola.mazzucato@arm.com, Cristian Marussi Subject: [PATCH 0/6] Add SCMI v3.2 Clock new CONFIGs support Date: Fri, 11 Aug 2023 17:14:40 +0100 Message-ID: <20230811161446.636253-1-cristian.marussi@arm.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230811_091554_811096_32E93DF6 X-CRM114-Status: GOOD ( 12.26 ) 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; it is marked as RFC since, even though trivial and tested in emulation, there are really at the moment NO real users for these new OEM-related clock operations. 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 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 [RFC] firmware: arm_scmi: Add Clock OEM config clock operations drivers/clk/clk-scmi.c | 31 ++++- drivers/firmware/arm_scmi/clock.c | 220 +++++++++++++++++++++++++++--- include/linux/scmi_protocol.h | 19 ++- 3 files changed, 240 insertions(+), 30 deletions(-)