On Mon, Jun 14, 2021 at 2:50 PM Vincent Guittot via Stratos-dev stratos-dev@op-lists.linaro.org wrote:>
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:
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>; }; };
But this example seem to be completely different from the ones I mentioned: The scmi node that you have here looks like it shows up under the root of the device tree, not below the virtio device that implements the scmi transport.
Arnd
On Mon, 14 Jun 2021 at 15:00, Arnd Bergmann arnd@kernel.org wrote:
On Mon, Jun 14, 2021 at 2:50 PM Vincent Guittot via Stratos-dev stratos-dev@op-lists.linaro.org wrote:>
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:
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>; }; };But this example seem to be completely different from the ones I mentioned: The scmi node that you have here looks like it shows up under the root of the device tree, not below the virtio device that implements the scmi transport.
I was thinking of something like below:
deviceX: deviceX@YYYYYYY { ... gpio = <&virtio_gpio 0>; ... };
virtio_mmio@a000000 { dma-coherent; interrupts = <0x0 0x10 0x1>; reg = <0x0 0xa000000 0x0 0x200>; compatible = "virtio,mmio";
virtio_gpio: protocol@22 { reg = <0x22>; }; };
Arnd
On Mon, Jun 14, 2021 at 3:24 PM Vincent Guittot vincent.guittot@linaro.org wrote:
On Mon, 14 Jun 2021 at 15:00, Arnd Bergmann arnd@kernel.org wrote:
On Mon, Jun 14, 2021 at 2:50 PM Vincent Guittot via Stratos-dev stratos-dev@op-lists.linaro.org wrote:>
But this example seem to be completely different from the ones I mentioned: The scmi node that you have here looks like it shows up under the root of the device tree, not below the virtio device that implements the scmi transport.
I was thinking of something like below:
deviceX: deviceX@YYYYYYY { ... gpio = <&virtio_gpio 0>; ... }; virtio_mmio@a000000 { dma-coherent; interrupts = <0x0 0x10 0x1>; reg = <0x0 0xa000000 0x0 0x200>; compatible = "virtio,mmio"; virtio_gpio: protocol@22 { reg = <0x22>; };
Encoding the device ID as "reg" seems somewhat odd, especially since there can only be one child for each virtio device. The other bus types use the "compatible" property instead of "reg" for this purpose. This is still redundant, since the type is also known from the contents, but it seems less unusual.
The gpio node in the example is usually called "gpio" or "gpio-controller", and it would then need the "gpio-controller" and "#gpio-cells" properties so other nodes can refer to it by phandle.
Arnd
On Mon, 14 Jun 2021 at 22:56, Arnd Bergmann arnd@kernel.org wrote:
On Mon, Jun 14, 2021 at 3:24 PM Vincent Guittot vincent.guittot@linaro.org wrote:
On Mon, 14 Jun 2021 at 15:00, Arnd Bergmann arnd@kernel.org wrote:
On Mon, Jun 14, 2021 at 2:50 PM Vincent Guittot via Stratos-dev stratos-dev@op-lists.linaro.org wrote:>
But this example seem to be completely different from the ones I mentioned: The scmi node that you have here looks like it shows up under the root of the device tree, not below the virtio device that implements the scmi transport.
I was thinking of something like below:
deviceX: deviceX@YYYYYYY { ... gpio = <&virtio_gpio 0>; ... }; virtio_mmio@a000000 { dma-coherent; interrupts = <0x0 0x10 0x1>; reg = <0x0 0xa000000 0x0 0x200>; compatible = "virtio,mmio"; virtio_gpio: protocol@22 { reg = <0x22>; };Encoding the device ID as "reg" seems somewhat odd, especially since there can only be one child for each virtio device. The other bus types use the "compatible" property instead of "reg" for this purpose. This is still redundant, since the type is also known from the contents, but it seems less unusual.
At least this ensures to match directly the protocol id instead of mapping a compatible string with the protocol id.
The gpio node in the example is usually called "gpio" or "gpio-controller", and it would then need the "gpio-controller" and "#gpio-cells" properties so other nodes can refer to it by phandle.
yes, This short example is just to show what I mean.
Arnd
stratos-dev@op-lists.linaro.org
-
Arnd Bergmann -
Vincent Guittot