On Mon, 14 Jun 2021 at 14:33, Arnd Bergmann arnd@kernel.org wrote:
On Mon, Jun 14, 2021 at 12:23 PM Viresh Kumar viresh.kumar@linaro.org wrote:
On 10-06-21, 15:22, Arnd Bergmann wrote:
Can you give an example of how this would be hooked up to other drivers using those gpios. Can you give an example of how using the "gpio-keys" or "gpio-leds" drivers in combination with virtio-gpio looks like in the DT?
Would qemu simply add the required DT properties to the device node that corresponds to the virtio device in this case?
From what I can tell, both the mmio and pci variants of virtio can have their dev->of_node populated, but I don't see the logic in register_virtio_device() that looks up the of_node of the virtio_device that the of_gpio code then tries to refer to.
To be honest, I haven't tried this yet and I was expecting it to be already taken care of. I was relying on the DTB automatically generated by Qemu to get the driver probed and didn't have a look at it as well.
I now understand that it won't be that straight forward. The same must be true for adding an i2c device to an i2c bus over virtio (The way I tested that earlier was by using the sysfs file to add a device to a bus).
Yes, correct, we had the same discussion about i2c. Again, this is relatively straightforward when the controller and the device attached to it (i2c controller/client or gpio controller/function) are both emulated by qemu, but a lot harder when the controller and device are implemented in different programs.
This may be something lacking generally for virtio-pci thing, not sure though.
I think most importantly we need a DT binding to describe what device nodes are supposed to look like underneath a virtio-mmio or virtio-pci device in order for a hypervisor to pass down the information to a guest OS in a generic way. We can probably borrow the USB naming, and replace compatible="usbVID,PID" with compatible="virtioDID", with the device ID in hexadecimal digits, such as "virtio22" for I2C (virtio device ID 34 == 0x22) if we decide to have a sub-node under the device, or we just point dev->of_node of the virtio device to the platform/pci device that is its parent in Linux.
Adding the Linux guest code to the virtio layer should be fairly straightforward, and I suppose it could be mostly copied from the corresponding code that added this for mmc in commit 25185f3f31c9 ("mmc: Add SDIO function devicetree subnode parsing") and for USB in commit 69bec7259853 ("USB: core: let USB device know device node") and 1a7e3948cb9f ("USB: add device-tree support for interfaces").
And something similar is also done with SCMI protocols which are defined in a SCMI node. A typical example:
cpu@0 { ... clocks = <&scmi_dvfs 0>; ... };
deviceX: deviceX@YYYYYYY { ... clocks = <&scmi_clk 0>; ... };
scmi: scmi { compatible = "arm,scmi-virtio"; #address-cells = <1>; #size-cells = <0>;
scmi_devpd: protocol@11 { reg = <0x11>; #power-domain-cells = <1>; };
scmi_clk: protocol@14 { reg = <0x14>; #clock-cells = <1>; };
scmi_sensors: protocol@15 { reg = <0x15>; #thermal-sensor-cells = <1>; };
scmi_dvfs: protocol@13 { reg = <0x13>; #clock-cells = <1>; }; };
Arnd