Attendees
- MIke
- Alex
- Ilias
- Viresh
- Bill
- Peter
- Don
- BillM
- Catalin (NXP)
- Vinchent
- Diana (NXP)
- Mark
- Randy
- Joakim
- Jens
- Bogdan Vlad (NXP)
- Francios
- Pratik (Qualcomm)
- Arnd
- Azedine (QC)
- Srivatsa (Qualcomm)
- Arnaund Pouliquen (ST)
- Souvik (Qualcomm)
- Review Action items
- Mike Holmes discussed the current status w.r.t Linux userspace API for RPMB, will raise EPIC
...
| Excerpt |
|---|
|
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.
- Arnd: What devices
- spi, i2c gpio - in progress
- BillM gpio expander over I2c
- BillM: Can bus: AZ: not interesting yet
- AZ: SCMI, Rust Alex
...