Mike Holmes discussed the current status w.r.t Linux userspace API for RPMB, will raise EPIC
Discussion items
Review for the plan for VirtIO enablement for low bandwidth interfaces such as I2C, SPI,
Discussion Points
AZ: What are Linaros plans for I2C
upstream for kernel & spec has been voted on for I2C - we will do a backend.
The useful part is having another virtio model - useful for measuring fat work queues
Are we going to talk to more than vhostuser? (Xen IOREQ?)
Do we want it to interface with real hardware (passthrough to real i2c HW?)
AZ - some form of security
BMills - a first step, have virtual I2C eeprom that can be read and written, QEMU probably has support already, to be useful demo you want i2c bus where you mix bridge, virtual etc. AZ: the direct assignment is an important issue.
BillM - Grey bus, it is not what we will tackle this cycle.
VG: rpmsg is a way to multiplex, already uses virtque. MP: intel has already published patches, perhaps we can find a common feature.
BillM: they have an audio device
Arnd: Grey bus may be useful for enumeration - does not provide much more than device tree, what about devices with no DT - call for examples
Arnd: limited hardware, single virt queue pair - mailbox shared memory - then you cant do 5 queues for low speed devices. Greybus can, rpmsg can, or nested virtqueue is a thought but there is no code.
Alex : we need to define a few messages, need a better name for a fat virtqueue
AB: 1st device : BIllM: emulate eeprom with file. Arnd there are several clocks eeproms etc already available.