Thanks Peter. I have set it up such that master device has qemu_irq array which it initializes using qdev_init_gpio_out with number of gpio lines going out and slave device calls qdev_init_gpio_in with a callback that should be called when irq is raised. Then I connect them together at higher level using qdev_connect_gpio_out as you said. Then master calls qemu_set_irq with 1 or 0 depending on whether the gpio is high or low.
This works, but not as I would expect. The handler that I supply to the init_gpio_in is only being called very infrequently - perhaps once every 50 toggles on the gpio pin. I need to make sure that it gets called every time master device calls qemu_set_irq. What's the mechanism behind this behavior and how can I deliver gpio change to the slave? On Tue, Aug 21, 2018 at 3:57 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 21 August 2018 at 14:29, Martin Schroeder via Qemu-devel > <qemu-devel@nongnu.org> wrote: > > I'd like to add a virtual device that is controlled by a couple of > > GPIO pins on my controller (cortex-m4) and a serial port. I suppose I > > can derive it from SSISlaveClass to make the new device a serial > > slave. > > > > But how do I connect GPIOs? > > > > I want the slave device to be notified when guest firmware toggles a > > gpio pin through the gpio driver which is an mmio device mapped into > > the gpio memory area. So the GPIO driver currently keeps the state of > > the pins internal to the driver. What I would like to do is somehow, > > without requiring that the GPIO driver knows about the connected slave > > device, deliver the notification of a gpio pin being toggled to the > > slave device. > > The GPIO device should expose its outbound GPIO lines > as qdev gpio lines. The slave device should have a GPIO line > which is an input qdev gpio. The board code then connects the two > together using > qdev_connect_gpio_out(your_gpio_device, i, > qdev_get_gpio_in(slavedevice, j)); > > which connects the GPIO controller's output GPIO i to > slave device's input GPIO j. > > There are also _named() versions of these so you can > give GPIO lines names rather than having them be unnamed > (which makes the code a bit easier to understand, especially > where the device isn't a gpio controller whose outputs are > all just "the GPIO lines"). > > thanks > -- PMM