On Fri, Jan 15, 2021 at 1:24 PM Alex Elder elder@linaro.org wrote:
On 1/12/21 8:47 AM, Arnd Bergmann via Stratos-dev wrote:
On Tue, Jan 12, 2021 at 12:24 PM Bill Mills bill.mills@linaro.org wrote:
On 1/12/21 5:57 AM, Viresh Kumar via Stratos-dev wrote:
On 16-12-20, 14:54, Arnd Bergmann wrote:
The problem we get into though is once we try to make this work for arbitrary i2c or spi devices. The kernel has around 1400 such drivers, and usually we use a device tree description based on a unique string for every such device plus additional properties for things like gpio lines or out-of-band interrupts.
I think what you're saying is that we already have DT-based drivers for existing hardware, and to abstract them with Greybus would likely require a special Greybus shim or something for every one of those.
Correct
The SPI controller will be accessible by the host OS (lets say both host and guest run Linux), the host will give/pass a manifest to the guest and the guest will send simple commands like read/write to the host. The Guest doesn't need minute details of how the controller is getting programmed, which is the responsibility of the host side controller driver which will have all this information from the DT passed from bootloader anyway. And so the manifest shouldn't be required to have equivalent of all DT properties.
Isn't it ?
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.
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.
I might be misunderstanding here but I *think* in the Greybus case, the details of how all signals (including interrupts) are implemented are the host's responsibility, and do not need to be visible to the guest.
You need a driver in the guest though that understands the device specific signaling and additional data. Let's look at a moderately complex example I picked at random, drivers/leds/leds-lp8501.c:
I assume the idea would be to not replace the entire driver with a greybus specific one, but to reused as much as possible from the existing code. The driver has no interrupts but it needs to access a gpio line and some device specific configuration data, which it can get either from a platform_data or from DT properties.
Passing such a device through greybus then requires at least these steps:
* allocate a unique device:vendor ID pair * create a lp8501 specific manifest binding for that ID * for the host, create an lp8501 specific greybus host driver to - read the device tree in the host, convert into manifest format according to the binding - open the raw i2c device and gpio line from user space - create virtual devices for these two, describe them in the manifest * for the guest, create an lp8501 greybus device driver for the vendor:device ID pair, to - interpret the manifest, convert data into lp55xx_platform_data - instantiate a gpio controller with one gpio line, - allocate a gpio number for that controller, add it to the platform data - instantiate a i2c host - instantiate a i2c device on that host, using the platform_data and the "lp8501" i2c_device_id string.
If a device has no DT properties or platform_data, and no gpio, reset, regulator, clock, or other dependendencies, some of the steps can be skipped, but at the minimum you still need device specific code in the guest to map the vendor:device ID to an i2c_device_id.
Arnd