On Fri, 18 Oct 2024 at 19:50, Octavian Purdila <ta...@google.com> wrote: > > On Fri, Oct 18, 2024 at 9:09 AM Peter Maydell <peter.mayd...@linaro.org> > wrote: > > 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.
So in the current design framework, the way you would model that kind of daughtercard is that you define a bus type corresponding to the daughtercard slot. For instance, for the Arduino Shield daughtercard spec supported by the mps3 boards, you would define the machine models to implement that bus (which wraps up i2c, gpio etc), and define some models of Shield daughtercards. Then users can use "-device tmp105-shield" on the command line and they don't need to know the internal details of which IRQ lines on the board are supposed to be used by the daughterboard, etc. This matches the real world hardware where the user plugs in a daughterboard rather than soldering wires directly between components. Directly exposing to users a "plug GPIO lines together" interface has some awkward sharp edges: * it is effectively making the QOM paths into user-facing APIs, which restricts our ability to refactor the implementation of the board without breaking existing user command lines. (In particular, anything using /machine/peripheral-anon/ is extremely vulnerable to changes in the board code.) * the user needs to know exactly how the board is wired up, including details like what GPIO inputs are free and which are used, and how each device orders its GPIO input lines. * at the moment there is no guard against trying to plug two GPIOs into a single output -- it just won't do the right thing. Currently we can say "that's a bug in QEMU C code if we do that", but a user-facing interface ought to be more robust. * how does this interact with hotpluggable devices? If you gpio-connect to a hotpluggable device and then hot-unplug it do we refuse the unplug, auto-disconnect the gpios, or just crash? As I say, the "I want to be able to plug devices together on the command line" usecase is real -- but I think that satisfying it is something we should do with a coherent approach to the whole problem, not piecemeal. thanks -- PMM
