From patchwork Fri Sep 18 16:23:09 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Hilber X-Patchwork-Id: 11785413 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5048F6CA for ; Fri, 18 Sep 2020 16:35:07 +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 0730D20872 for ; Fri, 18 Sep 2020 16:35:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="G5fBW5Cc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0730D20872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=opensynergy.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.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:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version: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=yQFOJ+ZNCP4+EHX5zHMfvrNU8BSWzZI/GJXLO7QWjQU=; b=G5fBW5CcPOfmwlNfq1/cyOgkks PzMzh3nLCC/WVYzn2zX86jfCYSMeBo12/7JYbwBHWL4Z7oG4gSm0ClQWrvnJ8f7Pfe0Tkrt9I7AbT oFgtIBJcUZggLe7rF+M5p+Qo+5QiBPwWh+/dX388VnGX4Evq9I3EBj910OJUh23QvLeQuM6Hpxopt WL1Ch6RNJwk350GoVtDtkikhujxewqgWj6uoY9SZnDg3006zH6mPA4lHWm+xrIm/UYWtqF2uhCpMl yYCWqDFNAwmnqDK2UUKXE856Vr7WvJrk0wJ3qkR0IH4wkulpj0xxdpyqZX6jqB1434gEyw5KB/6cL IN2STfCA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJJK1-0005KB-UO; Fri, 18 Sep 2020 16:33:17 +0000 Received: from plasma31.jpberlin.de ([80.241.56.82]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJJJy-0005JF-At for linux-arm-kernel@lists.infradead.org; Fri, 18 Sep 2020 16:33:16 +0000 Received: from spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) by plasma.jpberlin.de (Postfix) with ESMTP id 810E01025E4; Fri, 18 Sep 2020 18:26:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from plasma.jpberlin.de ([80.241.56.76]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id BIAa6MxQyu22; Fri, 18 Sep 2020 18:26:24 +0200 (CEST) Received: from webmail.opensynergy.com (unknown [217.66.60.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.opensynergy.com", Issuer "Starfield Secure Certificate Authority - G2" (not verified)) (Authenticated sender: opensynergy@jpberlin.de) by plasma.jpberlin.de (Postfix) with ESMTPSA id B07F7100971; Fri, 18 Sep 2020 18:26:23 +0200 (CEST) From: Peter Hilber To: , , , Subject: [RFC PATCH 0/7] firmware: arm_scmi: Add virtio transport Date: Fri, 18 Sep 2020 18:23:09 +0200 Message-ID: <20200918162311.254564-1-peter.hilber@opensynergy.com> MIME-Version: 1.0 X-ClientProxiedBy: SR-MAIL-01.open-synergy.com (10.26.10.21) To SR-MAIL-01.open-synergy.com (10.26.10.21) X-MBO-SPAM-Probability: X-Rspamd-Score: -3.87 / 15.00 / 15.00 X-Rspamd-Queue-Id: 810E01025E4 X-Rspamd-UID: d4e547 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200918_123314_596106_46D3FBAD X-CRM114-Status: GOOD ( 18.39 ) X-Spam-Score: -0.7 (/) X-Spam-Report: SpamAssassin version 3.4.4 on merlin.infradead.org summary: Content analysis details: (-0.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [80.241.56.82 listed in list.dnswl.org] 0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4) [80.241.56.82 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 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: Mark Rutland , jean-philippe@linaro.org, mikhail.golubev@opensynergy.com, Lorenzo Pieralisi , souvik.chakravarty@arm.com, igor.skalkin@opensynergy.com, "Michael S. Tsirkin" , Jason Wang , Jassi Brar , linux-kernel@vger.kernel.org, Rob Herring , Peter Hilber , anton.yakovlev@opensynergy.com, sudeep.holla@arm.com, alex.bennee@linaro.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org This series implements an SCMI virtio driver according to the virtio SCMI device spec patch v5 [1], after simple preparatory changes to the existing arm-scmi driver. The virtio transport differs in some respects from the existing shared-memory based SCMI transports. Message timeouts can be a problem if the virtio device (SCMI platform) does not have real-time properties. I set a high message rx timeout value which should work for non real-time virtio devices as well. There are other timeouts for delayed response and polling which were not addressed yet. Delayed responses are not really needed since, with the virtio transport, message responses may be transmitted out of order. Polling doesn't make sense at least for virtio devices without real-time behavior, in my understanding. There are some known issues which will be resolved before removing the RFC tag: - Further work is needed on the scmi_xfer management. Unlike shmem based transports, the virtio transport is actually exchanging messages with the SCMI agent through the scmi_xfer tx and rx buffers. In case of a message rx timeout, the arm-scmi driver could try to re-use the scmi_xfer, while that might still be used by the virtio device. I think part of the scmi_xfers_info bookkeeping could be optionally outsourced to the transport to remediate this. - After arm-scmi driver probe failure, or after remove, the scmi-virtio driver may still try to process and forward message responses from the virtio device. - We must be sure that the virtio transport option (such as virtio over MMIO) is available when the virtio SCMI device is probed. The series is based on for-next/scmi [2], on top of commit 66d90f6ecee7 ("firmware: arm_scmi: Enable building as a single module") The series was actually tested with a v5.4 based kernel, with the Base protocol and Sensor management protocol. The virtio SCMI device used was a proprietary implementation by OpenSynergy. Delayed responses were not tested. Any comments are very welcome. [1] https://lists.oasis-open.org/archives/virtio-comment/202005/msg00096.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git Igor Skalkin (7): firmware: arm_scmi, smccc, mailbox: Make shmem based transports optional firmware: arm_scmi: Document that max_msg is a per channel type limit firmware: arm_scmi: Add op to override max message # firmware: arm_scmi: Add per message transport data firmware: arm_scmi: Add xfer_init_buffers transport op dt-bindings: arm: Add virtio transport for SCMI firmware: arm_scmi: Add virtio transport .../devicetree/bindings/arm/arm,scmi.txt | 38 +- MAINTAINERS | 1 + drivers/firmware/Kconfig | 19 +- drivers/firmware/arm_scmi/Makefile | 3 +- drivers/firmware/arm_scmi/common.h | 31 +- drivers/firmware/arm_scmi/driver.c | 83 +++- drivers/firmware/arm_scmi/virtio.c | 470 ++++++++++++++++++ drivers/firmware/smccc/Kconfig | 1 + drivers/mailbox/Kconfig | 1 + include/uapi/linux/virtio_ids.h | 1 + include/uapi/linux/virtio_scmi.h | 41 ++ 11 files changed, 664 insertions(+), 25 deletions(-) create mode 100644 drivers/firmware/arm_scmi/virtio.c create mode 100644 include/uapi/linux/virtio_scmi.h base-commit: 66d90f6ecee755e9c19a119c9255e80091165498