Repost due mailist failure: virtio-gpio: add formal specification

["Enrico Weigelt, metux IT consult" <info@metux.net>]

Hello folks,


this is repost of the patch to formally introduce specification of the already
implemented and announced virtio-gpio from late 2020. Multiple attempts of
posting this patch over the last week didn't go through the list server due to
(yet not fully understood) technical problems. Tried resubscribing to both lists,
if you receive that mail, the problems is probably solved (at least for me :))

This patch introduces a now tex'ified version of the spec already submitted
in late 2020. Back then the official specification process was blocked by yet
missing formal / editorial steps, namely ID allocation and tex'ifying the
ascii text into the official specification document. Unfortunately, I had to put
it aside for a while due to more pressing tasks (keeping public infrastructure
up and running while in the middle of lockdown).

The current specification is semantically equal (fully compatible) to the ASCII
text version from late 2020, it only received terminology changes (e.g. replacing
"host" and "guest" by "driver" and "device") some clarifications.

In the mean time, the existing implementations for both device and driver side
are running in the field, in embedded and industrial applications, indicating that
general semantics should be fine. Maybe just some minor ambiguities in the spec
text yet to be ironed out.

Note:

Maybe the protocol might look a bit strange for someone who's just looking from the
VM perspective. The design decisions also have simplicistic hardware implementations
in mind, e.g. reuse message buffers for rx and tx (no need for actual memory management),
pretty direct wireup between IO drivers and buffer latches and hardwired decoding
(no actual sram required), and most importantly: more sophisticated features (e.g.
features often implemented in pinmuxes, like stength control, trigger thresholds,
inverters, debounce filters, etc) have intentionally left out at this point and will
be added as purely optional features in the future. The idea behind that decision is
to allow very minimal implementations of the gpio itself, and leave enough time for
careful consideration where those extra units actually be placed (e.g. shall virtio-gpio
have pinmux features at all ? several pro's and con's have to be weighted yet).

I've received positive feedback HW/VHDL engieers, stating that first hw implementation
was pretty straigthforward - for ASICS they're planning more optimizations in order
to reduce the number of gates by a magnitude. (Since I'm not an HW/VHDL expert, so I
can't comment much on this)

Finally I'm feeling very confident that virtio-gpio might show good case for using
virtio even in lo-profile / lo-power hardware and good change of replacing proprietary
interchip/intrachip protocols.


best regards,
--mtx