On 12-01-21, 06:24, Bill Mills wrote:
Yes for the interrupt for the SPI or I2C controller.
I presume Arnd is talking about side band signals from the devices. I2C and SPI don't have a client side concept of interrupt and the originator side (trying to not use the word master) would have to poll otherwise. So many devices hook up a side band interrupt request to a GPIO. Likewise an I2C EEPROM may have a write protect bit that is controlled by a GPIO.
Right and this bit controlled by GPIO needs to be handled by the host side driver, i.e. the regular driver for the controller's IP and not the greybus code. The guest of course shouldn't be required to do anything about this and shouldn't even know how the devices are connected.
Coordinating this between a virtual I2C and a virtual GPIO bank would be complicated to do in the manifest if each is a separate device.
However if we expand the definition of "I2C virtual device" to have an interrupt request line and a couple outputs, the details are in fact on the host side and the guest does not need to understand it all.
What would this mean for the 1400 devices in the kernel? Would we need to add a Greybus binding to the existing DT binding? That sounds like the wrong way. It would be nice to leverage the DT binding that was already in the kernel.
I hear that ACPI can bind to SPI and I2C. Is this true and how does that work?? (I ask for a reference. I am NOT suggesting we bring ACPI into this.)
It would be great if we had connector based DT in the kernel. Then you could generate a DT fragment for the virtual multifunction vPCI device and apply it at Greybus enumeration.
Didn't project Ara have this problem? Did it have a solution?
ARA was a bit different (the opposite) as the real hardware was controlled by the firmware running on the module and kernel doesn't need to know about the minute details. All it cares about is the transfers and not how they are done. And this is exactly what should be done here IMO.