On Fri, Oct 18, 2024 at 9:09 AM Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> On Fri, 18 Oct 2024 at 17:05, Daniel P. Berrangé <berra...@redhat.com> wrote:
> >
> > On Fri, Oct 18, 2024 at 04:38:24PM +0100, Peter Maydell wrote:
> > > On Thu, 10 Oct 2024 at 18:39, Octavian Purdila <ta...@google.com> wrote:
> > > >
> > > > From: Valentin Ghita <valentingh...@google.com>
> > > >
> > > > Add option to allow for connecting device GPIOs. This is useful when
> > > > adding a peripheral device from the command line which uses an
> > > > interrupt.
> > > >
> > > > It takes the following options:
> > > >
> > > > * in-dev-path, out-dev-path - required, the device canonical object
> > > > path (e.g. /machine/peripheral-anon/device[0],
> > > > /machine/iotkit/cluster0/armv7m0) for the devices that should have
> > > > their in <-> out GPIOs connected
> > > >
> > > > * in-gpio-name, out-gpio-name - optional, the name of the GPIO list;
> > > > if not specified, the unnamed GPIO list is used
> > > >
> > > > * in-gpio-index, out-gpio-index - optional, the index in the GPIO list
> > > > that identifies the GPIO to be used; if not specified 0 (the first
> > > > GPIO in the list) is used
> > > >
> > > > Usage example:
> > > >
> > > > # add the tmp105 sensor and connects its irq line to the CPU
> > > > qemu-system-arm \
> > > > --machine mps2-an505 \
> > > > --device tmp105,bus=/versatile_i2c/i2c,address=0x50 \
> > > > --connect-gpios out-dev-path=/machine/peripheral-anon/device[0],\
> > > > in-dev-path=/machine/iotkit/cluster0/armv7m0,in-gpio-index=100
> > >
> > >
> > > This seems to be moving down the path towards "create and
> > > wire up machines on the command line". We shouldn't
> > > be doing that ad-hoc with one small commandline option
> > > at a time, we should be doing it with a coherent plan.
> >
> > Yeah, as a general rule, adding new CLI args is pretty undesirable.
> > To avoid that we could utilize QOM for representing data:
> > eg a "gpio-connection" object:
> >
> > --object gpio-connection,out-dev-path=/machine/peripheral-anon/device[0],\
> > in-dev-path=/machine/iotkit/cluster0/armv7m0,in-gpio-index=100
> >
> > this would be OK if we're fine with some code somewhere that iterates
> > over the 'gpio-connection' object instances performing the wiring.
>
> Maybe, but as I say we would want an overall design for this,
> not a single "well this happens to let this one user do this
> one specific thing" approach.
>
> At the moment our design is "QEMU command line options are for
> doing the equivalent of plugging in PCI cards into slots, not
> for the equivalent of soldering chips onto boards". And in
> that view of the world "link this gpio line from the tmp105
> up to the armv7m interrupt controller" is not something to do on
> the command line, because it's definitely soldering wires.
> So for current QEMU the answer is "if the AN505 has a tmp105
> sensor, we should be creating it in the C code for the machine,
> and if it doesn't then we don't support creating it on the
> command line".
>
I should have used a better example, like:
qemu-system-arm \
--machine rt595-evk \
--device tmp105,bus=/flexcomm6-i2c,address=0x50 \
--connect-gpios in-dev-path=/machine/soc/gpio,in-gpio-index=22,\
out-dev-path=/machine/peripheral-anon/device[0]
This enables use-cases like plugging in daughter cards on a board that
has I2C/SPI/GPIO pins exposed on a header. IMO this is very similar to
plugging in PCI cards into slots.
