From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AAFA0C4363A for ; Wed, 28 Oct 2020 20:30:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 36CA5247FE for ; Wed, 28 Oct 2020 20:30:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2bG9FE2S" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36CA5247FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:Date:Subject: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=OYudDgX8kx/ScHabRhw77Eo9U1PbEP2ZxifXX3n65eI=; b=2bG9FE2S62QMYNkzjiZSNuC2c5 tTHwybaKc/cyQ+yoQGNghn5wHGRXkrQ7IiKi9MukNRd1fG73PNxsl6FW57aOi1Zg/C8iPjuS5oUgo yPSp3y/fXRaqZ+y8WnbxlhFkKmGSRuTCfsfLQigd3tWCYf4uwzL9Z3+Yaizx/SGtocqTpc/mx+nWk hNHS3C1w5KFtxRe+d7qJqXPf+B3rEpWpgSWYFlr2Kdnaikhy9oalk8y5byWgArkeRMiIhTcpPJJMD sh80ttYR9zdXEa7DRAhO/Pe2j+5Ga9FeFaQn64QT913wmOoqEVVZH31bHDErPKhIcSxv05OvUyj8d LqbXcnJQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXs4s-0005Oi-NY; Wed, 28 Oct 2020 20:29:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXs4p-0005Ng-W8 for linux-arm-kernel@lists.infradead.org; Wed, 28 Oct 2020 20:29:49 +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 741DB1A9A; Wed, 28 Oct 2020 13:29:43 -0700 (PDT) Received: from e120937-lin.home (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C8C663F66E; Wed, 28 Oct 2020 13:29:41 -0700 (PDT) From: Cristian Marussi To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 0/8] SCMI vendor protocols and modularization Date: Wed, 28 Oct 2020 20:29:06 +0000 Message-Id: <20201028202914.43662-1-cristian.marussi@arm.com> X-Mailer: git-send-email 2.17.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201028_162948_148013_990CB798 X-CRM114-Status: GOOD ( 20.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: f.fainelli@gmail.com, vincent.guittot@linaro.org, sudeep.holla@arm.com, thara.gopinath@linaro.org, cristian.marussi@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, souvik.chakravarty@arm.com, etienne.carriere@linaro.org, lukasz.luba@arm.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, The current SCMI implementation does not provide an interface to easily develop and include a custom vendor protocol implementation as prescribed by the SCMI standard, also because, there is not currently any custom protocol in the upstream to justify the development of a custom interface and its maintenance. Moreover the current interface exposes protocol operations to the SCMI driver users attaching per-protocol operations directly to the handle structure, which, in this way, tends to grow indefinitely for each new protocol addition. Beside this, protocols private data are also exposed via handle *_priv pointers, making such private data accessible also to the SCMI drivers even if neither really needed nor advisable. This series tris to address this simplifying the SCMI protocols interface and reducing it, roughly, to these common generic operations: handle->get_ops() / handle->put_ops() / handle->notify_ops() and a few related devres managed flavours. All protocols' private data pointers are removed from handle too and made accessible only to the protocols code through dedicated internal helpers. The concept of protocol handle is introduced in the SCMI protocol code to represent a protocol instance initialized against a specific SCMI instance(handle): so that all the new protocol code uses such protocol handles wherever previously SCMI handle was used: this enable tighter control of what is exposed to the protocol code vs the SCMI drivers. Moreover protocol initialization is moved away from device probe and now happens on demand when the first user shows up (first .get_ops), while de-initialization is performed once the last user of the protocol (even in terms of notifications) is gone, with the SCMI core taking care to perform all the needed underlying resource accounting. This way any new future standard or custom protocol implementation will expose a common unified interface which does not need to be extended endlessly: no need to maintain a custom interface only for vendor protos. SCMI drivers written on top of standard or custom protocols will use this same common interface to access any protocol operations. All existent upstream SCMI drivers are converted to this new interface. Leveraging this new centralized and common initialization flow, patches 5,7 take care also to refactor and simplify protocol-events registration and remove *notify_priv from the handle interface making it accessible only to the notification core. Finally, patch 8 builds on top of this new interface and introduces a mechanism to define an SCMI protocol as a full blown module (possibly loadable) while leaving the core dealing with proper resource accounting. Standard protocols are still kept as builtins, though. The whole SCMI stack can be built alternatively as a module (incudling all the standard protocols). On top of this series an example SCMI Custom protocol 0x99 and related SCMI Custom Dummy driver has been built and it is available at [2] as a series of DEBUG patches on top this same series. The current revision of this series still does not address the possibility of creating dynamically the SCMI devices: any new protocols must be added to the SCMI embedded module device table as of now, while it could be desirable to have such devices created dynamically whenever a new protocol is added and loaded into the system. The series is currently based on for-next/scmi [1] on top of: commit b9ceca6be432 ("firmware: arm_scmi: Fix duplicate workqueue name") Any feedback welcome. Thanks, Cristian --- v1 --> v2 - rebased on for-next/scmi v5.10-rc1 - introduced protocol handles - added devres managed devm_ variant for protocols operations - made all scmi_protocol refs const - introduced IDR to handle protocols instead of static array - refactored code around fast path [1]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi [2]:https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_modules_ext_V2/ Cristian Marussi (8): firmware: arm_scmi: review protocol registration interface firmware: arm_scmi: introduce protocol handles firmware: arm_scmi: introduce new protocol operations support firmware: arm_scmi: make notifications aware of protocol usage firmware: arm_scmi: refactor events registration firmware: arm_scmi: port all protocols and drivers to the new API firmware: arm_scmi: make notify_priv really private firmware: arm_scmi: add protocol modularization support drivers/clk/clk-scmi.c | 27 +- drivers/cpufreq/scmi-cpufreq.c | 38 +- drivers/firmware/arm_scmi/base.c | 140 +++--- drivers/firmware/arm_scmi/bus.c | 70 +-- drivers/firmware/arm_scmi/clock.c | 127 +++--- drivers/firmware/arm_scmi/common.h | 114 ++++- drivers/firmware/arm_scmi/driver.c | 474 +++++++++++++++++++-- drivers/firmware/arm_scmi/notify.c | 303 ++++++++++--- drivers/firmware/arm_scmi/notify.h | 38 +- drivers/firmware/arm_scmi/perf.c | 257 +++++------ drivers/firmware/arm_scmi/power.c | 132 +++--- drivers/firmware/arm_scmi/reset.c | 144 ++++--- drivers/firmware/arm_scmi/scmi_pm_domain.c | 26 +- drivers/firmware/arm_scmi/sensors.c | 135 +++--- drivers/firmware/arm_scmi/system.c | 60 +-- drivers/hwmon/scmi-hwmon.c | 24 +- drivers/reset/reset-scmi.c | 33 +- include/linux/scmi_protocol.h | 142 +++--- 18 files changed, 1569 insertions(+), 715 deletions(-) -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel