SPI support for the virt platform

SPI support for the virt platform

[Marcelo Schmitt]

Hi,

I'd like to know the opinion of the QEMU community on some topics.

In 2021, a pair of patch sets for drivers of the Linux IIO subsystem was
proposed based on some QEMU hacks that added virtual devices with which
it was possible to test the proposed modifications to the Linux kernel
[1, 2, 3].

Most Linux IIO drivers connect to the system through either SPI or I2C.
So, it ends up that these buses are needed to do some tests on IIO
drivers. Because of that, those QEMU changes included hacks to the virt
platform to add SPI or I2C buses.

The documentation says that virt is a generic virtual platform [4]. In
this regard, adding more buses to virt could turn the platform into
something less generic. However, if support for SPI/I2C were added, then
it would reduce the effort needed to develop virtual devices to aid
driver testing. Before putting effort to develop something concrete, I'd
like to ask just to make sure:
Would SPI/I2C support be a good addition to QEMU virt?

Another possibility would be to add support for SPI and I2C buses on
Raspberry Pi boards emulation [5]. Would this be a better idea?

Also, the QEMU devices developed could be upstreamed. At first, I
thought that developing virtual devices would be a win-win situation in
which we could extend Linux's test coverage and add support for new QEMU
devices. However, as these would be dummy devices, I'm not sure how QEMU
would benefit from them. Anyhow, I'd appreciate it if anyone could give
a word about that.


Thanks,
Marcelo

[1] https://lore.kernel.org/linux-iio/20210314181511.531414-1-jic23@kernel.org/
[2] https://lore.kernel.org/linux-iio/20210614113507.897732-1-jic23@kernel.org/
[3] https://github.com/jic23/qemu
[4] https://qemu-project.gitlab.io/qemu/system/arm/virt.html
[5] https://qemu-project.gitlab.io/qemu/system/arm/raspi.html

Re: SPI support for the virt platform

[Jonathan Cameron via]

On Mon, 28 Feb 2022 23:26:05 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> Hi,
> 
> I'd like to know the opinion of the QEMU community on some topics.
> 
> In 2021, a pair of patch sets for drivers of the Linux IIO subsystem was
> proposed based on some QEMU hacks that added virtual devices with which
> it was possible to test the proposed modifications to the Linux kernel
> [1, 2, 3].
> 
> Most Linux IIO drivers connect to the system through either SPI or I2C.
> So, it ends up that these buses are needed to do some tests on IIO
> drivers. Because of that, those QEMU changes included hacks to the virt
> platform to add SPI or I2C buses.
> 
> The documentation says that virt is a generic virtual platform [4]. In
> this regard, adding more buses to virt could turn the platform into
> something less generic. However, if support for SPI/I2C were added, then
> it would reduce the effort needed to develop virtual devices to aid
> driver testing. Before putting effort to develop something concrete, I'd
> like to ask just to make sure:
> Would SPI/I2C support be a good addition to QEMU virt?

Hi Marcelo,

With my IIO kernel maintainer hat on, I'm keen to have a better platform
for this than my various hacks so very happy to see this topic raised!

The advantage of arm-virt is the setup code and dt/acpi table generation
is all more or less in one place which makes things nice and flexible
for configuration.

It might be possible to do something that is well isolated in separate file
optionally built/runtime enabled so as to not bloat arm-virt for other
usecases.

Trying to enable generic configuration for i2c and spi devices is via
-device looks hard to me as there are normally gpio/irq type
requirements but perhaps it can be done and that would make things
more flexible.  Mind you for a test platform I have no problem with
having a 'board' that has lots of i2c and SPI devices always configured. 

> 
> Another possibility would be to add support for SPI and I2C buses on
> Raspberry Pi boards emulation [5]. Would this be a better idea?

It would be an option though maybe not so easy to mess around with and
extending those with devices not commonly seen might also be controversial.

Thinking out of the box, we could emulate a PCI card and put everything on
that but we'd probably be inventing hardware to emulate as I don't know
of a suitable device. There are real usb-i2c/spi devices but those aren't
entirely trivial to use and you still need to describe non discoverable
buses somehow.

> 
> Also, the QEMU devices developed could be upstreamed. At first, I
> thought that developing virtual devices would be a win-win situation in
> which we could extend Linux's test coverage and add support for new QEMU
> devices. However, as these would be dummy devices, I'm not sure how QEMU
> would benefit from them. Anyhow, I'd appreciate it if anyone could give
> a word about that.

Needs someone to commit to maintaining the code + tests etc.

Whilst I don't mind helping, I don't have the bandwidth to do too much
on this in Qemu, but sounds like you might be the perfect person Marcelo :)

Jonathan

> 
> 
> Thanks,
> Marcelo
> 
> [1] https://lore.kernel.org/linux-iio/20210314181511.531414-1-jic23@kernel.org/
> [2] https://lore.kernel.org/linux-iio/20210614113507.897732-1-jic23@kernel.org/
> [3] https://github.com/jic23/qemu
> [4] https://qemu-project.gitlab.io/qemu/system/arm/virt.html
> [5] https://qemu-project.gitlab.io/qemu/system/arm/raspi.html
>