linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hilber <peter.hilber@opensynergy.com>
To: <linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>,
	<virtualization@lists.linux-foundation.org>,
	<virtio-dev@lists.oasis-open.org>
Cc: jean-philippe@linaro.org, mikhail.golubev@opensynergy.com,
	souvik.chakravarty@arm.com, igor.skalkin@opensynergy.com,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Peter Hilber <peter.hilber@opensynergy.com>,
	anton.yakovlev@opensynergy.com, sudeep.holla@arm.com,
	alex.bennee@linaro.org
Subject: [RFC PATCH v2 00/10] firmware: arm_scmi: Add virtio transport
Date: Thu, 5 Nov 2020 22:21:06 +0100	[thread overview]
Message-ID: <20201105212116.411422-1-peter.hilber@opensynergy.com> (raw)

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 b9ceca6be432 ("firmware: arm_scmi: Fix duplicate workqueue name")

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.

Changes in RFC v2:

- Remove the DT virtio_transport phandle, since the SCMI virtio device may
  not be known in advance. Instead, use the first suitable probed device.
  Change due to Rob Herring's comment.

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

Peter Hilber (3):
  firmware: arm_scmi: Add optional link_supplier() transport op
  firmware: arm_scmi: Add per-device transport private info
  firmware: arm_scmi: Add is_scmi_protocol_device()

 .../devicetree/bindings/arm/arm,scmi.txt      |  35 +-
 MAINTAINERS                                   |   1 +
 drivers/firmware/Kconfig                      |  19 +-
 drivers/firmware/arm_scmi/Makefile            |   3 +-
 drivers/firmware/arm_scmi/bus.c               |   5 +
 drivers/firmware/arm_scmi/common.h            |  37 +-
 drivers/firmware/arm_scmi/driver.c            | 124 ++++-
 drivers/firmware/arm_scmi/virtio.c            | 493 ++++++++++++++++++
 drivers/firmware/smccc/Kconfig                |   1 +
 drivers/mailbox/Kconfig                       |   1 +
 include/uapi/linux/virtio_ids.h               |   1 +
 include/uapi/linux/virtio_scmi.h              |  41 ++
 12 files changed, 736 insertions(+), 25 deletions(-)
 create mode 100644 drivers/firmware/arm_scmi/virtio.c
 create mode 100644 include/uapi/linux/virtio_scmi.h


base-commit: b9ceca6be43233845be70792be9b5ab315d2e010
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2020-11-05 21:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05 21:21 Peter Hilber [this message]
2020-11-05 21:21 ` [RFC PATCH v2 01/10] firmware: arm_scmi, smccc, mailbox: Make shmem based transports optional Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 02/10] firmware: arm_scmi: Document that max_msg is a per channel type limit Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 03/10] firmware: arm_scmi: Add op to override max message # Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 04/10] firmware: arm_scmi: Add per message transport data Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 05/10] firmware: arm_scmi: Add xfer_init_buffers transport op Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 06/10] firmware: arm_scmi: Add optional link_supplier() " Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 07/10] firmware: arm_scmi: Add per-device transport private info Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 08/10] firmware: arm_scmi: Add is_scmi_protocol_device() Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 09/10] dt-bindings: arm: Add virtio transport for SCMI Peter Hilber
2020-11-05 21:21 ` [RFC PATCH v2 10/10] firmware: arm_scmi: Add virtio transport Peter Hilber
2020-11-10 21:32   ` Cristian Marussi
2020-11-12 10:57     ` Peter Hilber
2020-11-17 21:20       ` Cristian Marussi
2021-04-08  3:45   ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201105212116.411422-1-peter.hilber@opensynergy.com \
    --to=peter.hilber@opensynergy.com \
    --cc=alex.bennee@linaro.org \
    --cc=anton.yakovlev@opensynergy.com \
    --cc=devicetree@vger.kernel.org \
    --cc=igor.skalkin@opensynergy.com \
    --cc=jean-philippe@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikhail.golubev@opensynergy.com \
    --cc=robh+dt@kernel.org \
    --cc=souvik.chakravarty@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    --subject='Re: [RFC PATCH v2 00/10] firmware: arm_scmi: Add virtio transport' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).