[lkml]   [2020]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC PATCH 0/7] firmware: arm_scmi: Add virtio transport
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

Any comments are very welcome.


Igor Skalkin (7):
firmware: arm_scmi, smccc, mailbox: Make shmem based transports
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 +-
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

 \ /
  Last update: 2020-09-18 18:34    [W:0.094 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site