From: Viresh Kumar <viresh.kumar@linaro.org> To: Arnd Bergmann <arnd@kernel.org> Cc: "Rob Herring" <robh+dt@kernel.org>, "Jason Wang" <jasowang@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, "Jean-Philippe Brucker" <jean-philippe@linaro.org>, "Vincent Guittot" <vincent.guittot@linaro.org>, "Bill Mills" <bill.mills@linaro.org>, "Alex Bennée" <alex.bennee@linaro.org>, "Enrico Weigelt, metux IT consult" <info@metux.net>, "Jie Deng" <jie.deng@intel.com>, DTML <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" <virtualization@lists.linux-foundation.org> Subject: Re: [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode Date: Wed, 14 Jul 2021 07:56:30 +0530 [thread overview] Message-ID: <20210714022630.d7vrazygmbooflcf@vireshk-i7> (raw) In-Reply-To: <CAK8P3a3Gve=M9GF-E+2OJED1Hd1qngxOkVSO15wB0jVWK8D0_Q@mail.gmail.com> On 13-07-21, 22:34, Arnd Bergmann wrote: > On Tue, Jul 13, 2021 at 9:35 PM Rob Herring <robh+dt@kernel.org> wrote: > > There shouldn't be. We have nodes be multiple providers (e.g clocks > > and resets) already. > > I think this would be a little different, but it can still work. There is in > fact already some precedent of doing this, with Jean-Philippe's virtio-iommu > binding, which is documented in both > > Documentation/devicetree/bindings/virtio/iommu.txt > Documentation/devicetree/bindings/virtio/mmio.txt > > Unfortunately, those are still slightly different from where I think we should > be going here, but it's probably close enough to fit into the general > system. > > What we have with virtio-iommu is two special hacks: > - on virtio-mmio, a node with 'compatible="virtio,mmio"' may optionally > have an '#iommu-cells=<1>', in which case we assume it's an iommu. > - for virtio-pci, the node has the standard PCI 'reg' property but a special > 'compatible="virtio,pci-iommu"' property that I think is different from any > other PCI node. > > I think for other virtio devices, we should come up with a way to define a > binding per device (i2c, gpio, ...) without needing to cram this into the > "virtio,mmio" binding or coming up with special compatible strings for > PCI devices. > > Having a child device for the virtio device type gives a better separation > here, since it lets you have two nodes with 'compatible' strings that each > make sense for their respective parent buses: The parent is either a PCI > device or a plain mmio based device, and the child is a virtio device with > its own namespace for compatible values. As you say, the downside is > that this requires an extra node that is redundant because there is always > a 1:1 relation with its parent. > > Having a combined node gets rid of the redundancy but if we want to > identify the device for the purpose of defining a custom binding, it would have > to have two compatible strings, something like > > compatible="virtio,mmio", "virtio,device34"; > > for a virtio-mmio device of device-id 34 (i2c), or a PCI device with > > compatible="pci1af4,1041", "virtio,device34"; > > which also does not quite feel right. I agree that even if the device is discoverable at runtime, we should still have some sort of stuff in DT to distinguish the devices, and "virtio,deviceDID" sounds good enough for that, considering that we already do it for USB, etc. And I am fine with both the ways, a new node or just using the parent node. So whatever you guys decide is fine. > > Direct userspace access to I2C, GPIO, etc. has its issues, we're going > > to repeat that with guests? > > Passing through the i2c or gpio access from a Linux host is just one > way to use it, you could do the same with an emulated i2c device > from qemu, and you could have a fake i2c device behind a virtio-i2c > controller. Or it can be firmware controlled device as well, as Rob said earlier. I think that's what Vincent will be doing for SCMI. Though all I have tested until now is direct userspace access. -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org> To: Arnd Bergmann <arnd@kernel.org> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>, Vincent Guittot <vincent.guittot@linaro.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Enrico Weigelt, metux IT consult" <info@metux.net>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" <virtualization@lists.linux-foundation.org>, DTML <devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Bill Mills <bill.mills@linaro.org> Subject: Re: [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode Date: Wed, 14 Jul 2021 07:56:30 +0530 [thread overview] Message-ID: <20210714022630.d7vrazygmbooflcf@vireshk-i7> (raw) In-Reply-To: <CAK8P3a3Gve=M9GF-E+2OJED1Hd1qngxOkVSO15wB0jVWK8D0_Q@mail.gmail.com> On 13-07-21, 22:34, Arnd Bergmann wrote: > On Tue, Jul 13, 2021 at 9:35 PM Rob Herring <robh+dt@kernel.org> wrote: > > There shouldn't be. We have nodes be multiple providers (e.g clocks > > and resets) already. > > I think this would be a little different, but it can still work. There is in > fact already some precedent of doing this, with Jean-Philippe's virtio-iommu > binding, which is documented in both > > Documentation/devicetree/bindings/virtio/iommu.txt > Documentation/devicetree/bindings/virtio/mmio.txt > > Unfortunately, those are still slightly different from where I think we should > be going here, but it's probably close enough to fit into the general > system. > > What we have with virtio-iommu is two special hacks: > - on virtio-mmio, a node with 'compatible="virtio,mmio"' may optionally > have an '#iommu-cells=<1>', in which case we assume it's an iommu. > - for virtio-pci, the node has the standard PCI 'reg' property but a special > 'compatible="virtio,pci-iommu"' property that I think is different from any > other PCI node. > > I think for other virtio devices, we should come up with a way to define a > binding per device (i2c, gpio, ...) without needing to cram this into the > "virtio,mmio" binding or coming up with special compatible strings for > PCI devices. > > Having a child device for the virtio device type gives a better separation > here, since it lets you have two nodes with 'compatible' strings that each > make sense for their respective parent buses: The parent is either a PCI > device or a plain mmio based device, and the child is a virtio device with > its own namespace for compatible values. As you say, the downside is > that this requires an extra node that is redundant because there is always > a 1:1 relation with its parent. > > Having a combined node gets rid of the redundancy but if we want to > identify the device for the purpose of defining a custom binding, it would have > to have two compatible strings, something like > > compatible="virtio,mmio", "virtio,device34"; > > for a virtio-mmio device of device-id 34 (i2c), or a PCI device with > > compatible="pci1af4,1041", "virtio,device34"; > > which also does not quite feel right. I agree that even if the device is discoverable at runtime, we should still have some sort of stuff in DT to distinguish the devices, and "virtio,deviceDID" sounds good enough for that, considering that we already do it for USB, etc. And I am fine with both the ways, a new node or just using the parent node. So whatever you guys decide is fine. > > Direct userspace access to I2C, GPIO, etc. has its issues, we're going > > to repeat that with guests? > > Passing through the i2c or gpio access from a Linux host is just one > way to use it, you could do the same with an emulated i2c device > from qemu, and you could have a fake i2c device behind a virtio-i2c > controller. Or it can be firmware controlled device as well, as Rob said earlier. I think that's what Vincent will be doing for SCMI. Though all I have tested until now is direct userspace access. -- viresh _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-07-14 2:26 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-13 10:50 [PATCH 0/5] virtio: Parse virtio-device nodes from DT Viresh Kumar 2021-07-13 10:50 ` Viresh Kumar 2021-07-13 10:50 ` [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode Viresh Kumar 2021-07-13 10:50 ` Viresh Kumar 2021-07-13 12:32 ` Arnd Bergmann 2021-07-14 2:28 ` Viresh Kumar 2021-07-14 2:28 ` Viresh Kumar 2021-07-13 14:43 ` Rob Herring 2021-07-13 15:19 ` Viresh Kumar 2021-07-13 15:19 ` Viresh Kumar 2021-07-13 19:34 ` Rob Herring 2021-07-13 20:34 ` Arnd Bergmann 2021-07-14 2:26 ` Viresh Kumar [this message] 2021-07-14 2:26 ` Viresh Kumar 2021-07-14 11:40 ` Viresh Kumar 2021-07-14 11:40 ` Viresh Kumar 2021-07-14 8:20 ` Jean-Philippe Brucker 2021-07-14 8:20 ` Jean-Philippe Brucker 2021-07-14 15:43 ` Rob Herring 2021-07-14 21:07 ` Arnd Bergmann 2021-07-19 10:33 ` Viresh Kumar 2021-07-19 10:33 ` Viresh Kumar 2021-07-19 12:04 ` Arnd Bergmann 2021-07-14 2:19 ` Viresh Kumar 2021-07-14 2:19 ` Viresh Kumar 2021-07-13 10:50 ` [PATCH 2/5] virtio_mmio: Bind virtio device to device-tree node Viresh Kumar 2021-07-13 10:50 ` Viresh Kumar 2021-07-13 12:26 ` Arnd Bergmann 2021-07-14 3:11 ` Viresh Kumar 2021-07-14 3:11 ` Viresh Kumar 2021-07-13 10:50 ` [PATCH 3/5] dt-bindings: i2c: Add bindings for i2c-virtio Viresh Kumar 2021-07-13 10:50 ` Viresh Kumar 2021-07-13 14:03 ` Rob Herring 2021-07-13 14:03 ` Rob Herring 2021-07-13 10:50 ` [PATCH 4/5] i2c: virtio: Update i2c-adapter's of_node Viresh Kumar 2021-07-13 10:50 ` Viresh Kumar 2021-07-13 10:50 ` [PATCH 5/5] dt-bindings: gpio: Add bindings for gpio-virtio Viresh Kumar 2021-07-13 10:50 ` Viresh Kumar 2021-07-13 14:03 ` Rob Herring 2021-07-13 14:03 ` Rob Herring 2021-07-13 14:46 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210714022630.d7vrazygmbooflcf@vireshk-i7 \ --to=viresh.kumar@linaro.org \ --cc=alex.bennee@linaro.org \ --cc=arnd@kernel.org \ --cc=bill.mills@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=info@metux.net \ --cc=jasowang@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=jie.deng@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=robh+dt@kernel.org \ --cc=vincent.guittot@linaro.org \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.