Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5966159pxb; Mon, 14 Feb 2022 11:53:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJx9ILvAbYattNVB04SV3MM3VL2UbOb1/fpIvjxOLoNk4dOCwyBisYif1A2dcwVMgs8V8zBV X-Received: by 2002:a05:6a00:1c6e:: with SMTP id s46mr704535pfw.56.1644868430837; Mon, 14 Feb 2022 11:53:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644868430; cv=none; d=google.com; s=arc-20160816; b=yBTIWl0For3D6lx6nWF6mCUv95wI8g9CQja/JVGiSii+EXWw/gss5Mnhg5zel68pQy pFCVBK/jufwDsiZrYFe9Lo11BHK3BQmYI4nDP/uPASwYyykSJvlWGCsF6zGBPSj7JOOZ ii7nImyiIQyUmD2wI4GthSDBRyaVRTdkNKlx8IeiC3UssNFfWNPVsAaqE3+CHgYxxhpm S/ySSFIIi9RLROYa75Ro8fiDPujrW34yw69arEo7etwPv8NMSxqFXM6IDyCCPRGwx/BM ekuzWtR59m9kvb5gRRE9AgrjIOCf2h3zrQbPs0lqxqtuRjdNIg/fZJ9NYBPWgBh4Cvgu LDeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=ZORj/dTTQvnK+D0BRoHNQcfXmZlMKUp6ftLLz8C+csc=; b=G6HW3BpgZpm/wwGlyqAsFK1+C8ZfFWmxRJT+/My7JpXrwE3fc2gHpYe0Qq64Sy5W8n AG/kmPo+xMWFYgP00+dNc0M0mNce1qHc95WtjhteCGhEfAZlGgV79a7rRwY42gt4OKLi ZiPRhsd48qNW+QYIhZlg4QtLcQtsmx0JWK2Bdr7fOI/yOgvomviPCvSDyyAUj7VC3Mf3 xFBpHV1ijYgsqhp3e9kvzGYIHl0Vh575O+y5E+vE8waL0465E7+gxMZb/yMLCYe/HoQy ccUUulHeB4PMkYPyz/Hwpxt/x1kWb2bx3k6RPsqCJ1ixG1ebwu45iPNpj8B4mr7cNdM+ NRWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id gt14si11811524pjb.119.2022.02.14.11.53.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 11:53:50 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 192069E57A; Mon, 14 Feb 2022 11:36:19 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238051AbiBMT7F (ORCPT + 99 others); Sun, 13 Feb 2022 14:59:05 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:39260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231842AbiBMT7E (ORCPT ); Sun, 13 Feb 2022 14:59:04 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0600343EF1 for ; Sun, 13 Feb 2022 11:58:57 -0800 (PST) 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 7367F2B; Sun, 13 Feb 2022 11:58:57 -0800 (PST) Received: from e120937-lin.home (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CE4CB3F70D; Sun, 13 Feb 2022 11:58:55 -0800 (PST) From: Cristian Marussi To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@Huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, peter.hilber@opensynergy.com, igor.skalkin@opensynergy.com, cristian.marussi@arm.com Subject: [PATCH v4 0/8] Add SCMI Virtio & Clock atomic support Date: Sun, 13 Feb 2022 19:58:24 +0000 Message-Id: <20220213195832.27932-1-cristian.marussi@arm.com> X-Mailer: git-send-email 2.17.1 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Hi, This small series is the tail-subset of the previous V8 series about atomic support in SCMI [1], whose 8-patches head-subset has now been queued on [2]; as such, it is based on [2] on top of tag scmi-updates-5.17: commit 94d0cd1da14a ("firmware: arm_scmi: Add new parameter to mark_txdone") Patch [1/8] substitute virtio-scmi ready flag and lock with a reference counter to keep track of vio channels lifetime while removing the need of a wide spinlocked section (that would cause issues with introduction of virtio polling support) Patch [2/8] adds a few helpers to handle the TX free_list and a dedicated spinlock to reduce the reliance on the main one. Patch [3/8] adds polling mode to SCMI VirtIO transport in order to support atomic operations on such transport. Patches [4,5/8] introduce a new optional SCMI binding, atomic-threshold-us, to configure a platform specific time threshold used in the following patches to select with a finer grain which SCMI resources should be eligible for atomic operations when requested. Patch [6/8] exposes new SCMI Clock protocol operations to allow an SCMI user to request atomic mode on clock enable commands. Patch [7/8] adds support to SCMI Clock protocol for a new clock attributes field which advertises typical enable latency for a specific resource. Finally patch [8/8] add support for atomic operations to the SCMI clock driver; the underlying logic here is that we register with the Clock framework atomic-capable clock resources if and only if the backing SCMI transport is capable of atomic operations AND the specific clock resource has been advertised by the SCMI platform as having: clock_enable_latency <= atomic-threshold-us The idea is to avoid costly atomic busy-waiting for resources that have been advertised as 'slow' to operate upon. (i.e. a PLL vs a gating clock) To ease testing the whole series can be find at [3]. Any feedback/testing welcome as usual. Thanks, Cristian [1]: https://lore.kernel.org/linux-arm-kernel/20211220195646.44498-1-cristian.marussi@arm.com/ [2]: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/tag/?h=scmi-updates-5.17 [3]: https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_atomic_clk_virtio_V4/ --- V3 --> V4 - renamed optional DT property to atomic-threshold-us V2 --> V3 - split out virtio_ring RFC patch into a distinct series - calling virtqueue_broke_device when cleaning up channel - removed RFC tags from CLK related patches V1 --> V2 - added vio channel refcount support patch - reviewed free_list support and usage - added virtio_ring RFC patch - shrinked spinlocked section within virtio_poll_done to exclude virtqueue_poll call - removed poll_lock - use vio channel refcount acquire/release logic when polling - using new free_list accessors - added new dedicated pending_lock to access pending_cmds_list - fixed a few comments Cristian Marussi (8): firmware: arm_scmi: Add a virtio channel refcount firmware: arm_scmi: Review virtio free_list handling firmware: arm_scmi: Add atomic mode support to virtio transport dt-bindings: firmware: arm,scmi: Add atomic-threshold-us optional property firmware: arm_scmi: Support optional system wide atomic-threshold-us firmware: arm_scmi: Add atomic support to clock protocol firmware: arm_scmi: Add support for clock_enable_latency clk: scmi: Support atomic clock enable/disable API .../bindings/firmware/arm,scmi.yaml | 11 + drivers/clk/clk-scmi.c | 71 ++- drivers/firmware/arm_scmi/Kconfig | 15 + drivers/firmware/arm_scmi/clock.c | 34 +- drivers/firmware/arm_scmi/driver.c | 36 +- drivers/firmware/arm_scmi/virtio.c | 495 +++++++++++++++--- include/linux/scmi_protocol.h | 9 +- 7 files changed, 566 insertions(+), 105 deletions(-) -- 2.17.1