Re: virtio-spi message boundaries

Hello,

since there was no reply to this, let me try to rephrase the perceived
shortcoming of the specification more concisely.

It seems to me that the current spec and the proposed Linux driver do
not allow the VIRTIO SPI device implemented according to this spec to
figure out the exact SPI message boundaries.

I have a Linux VM running the VIRTIO SPI driver. It is connected via
VIRTIO SPI to a real-world bmp280 device driven by our native VIRTIO SPI
device driver (which is out of the Linux VM). The problem is that any
information about SPI message boundaries is lost in the VIRTIO SPI
protocol. BMP280 is sensitive to premature chip-select disabling as it
forgets what it was doing before and switches to I2C mode immediately
when CS goes inactive. With the current VIRTIO SPI spec, every transfer
looks like a separate SPI message.

I was able to overcome this issue by slightly modifying the
specification (and also the Linux driver) to allow the last transfer of
an SPI message to be signaled in one of the reserved bytes of the VIRTIO
SPI transfer. Thus our device driver was able to reconstruct the SPI
message boundaries and deselect the CS correctly.

Am I overlooking some other mechanism that should be used to achieve the
same goal instead of my workaround?

Cheers,
Jakub


On 7/28/25 11:39 AM, Jakub Jermář wrote:
> Hello,
> 
> the current virtio-spi draft mentions the concept of SPI messages in
> several places, for example:
> 
>   cs_change_supported indicates if the device supports to toggle
>   chipselect after each transfer in one message: 0: unsupported,
>   chipselect will be kept in active state throughout the message
>   transaction; 1: supported.
>   Note: Message here contains a sequence of SPI transfers.
> 
> and also:
> 
>   Note: Just as one message contains a sequence of transfers, one
>   transfer may contain a sequence of words.
> 
> These wordings appeared in the virtio-spi device specification patch v5
> and have remained in the specification draft ever since. I was, however,
> unable to find any discussion that preceded their introduction into the
> spec (as far as the concept of messages themselves is concerned).
> 
> Now, I was wondering how does the virtio-spi device figure out which SPI
> transfers belong to the same SPI message. SPI messages are important
> wrt. to correct toggling of the chip select line but the spec is quite
> vague on how to find their boundaries.
> 
> I could imagine, for example, that an SPI message is formed by chaining
> the respective virtio-spi transfers of a message together so that a
> message is determined by the head descriptor of the first transfer. But
> this is not stated anywhere. I was hoping to be able to infer this from
> the proposed virtio-spi Linux driver, but it does not seem to handle
> messages at all in its latest version.
> 
> Has anyone figured this out already?
> 
> Cheers,
> Jakub