Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann wrote: > On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij wrote: > > On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult > > wrote: > > > What we need to understand is if your new usecase is an outlier > > so it is simplest modeled by a "mock" irq_chip or we have to design > > something new altogether like notifications on changes. I suspect > > irq_chip would be best because all drivers using GPIOs for interrupts > > are expecting interrupts, and it would be an enormous task to > > change them all and really annoying to create a new mechanism > > on the side. > > I would expect the platform abstraction to actually be close enough > to a chained irqchip that it actually works: the notification should > come in via vring_interrupt(), which is a normal interrupt handler > that calls vq->vq.callback(), calling generic_handle_irq() (and > possibly chained_irq_enter()/chained_irq_exit() around it) like the > other gpio drivers do should just work here I think, and if it did > not, then I would expect this to be just a bug in the driver rather > than something missing in the gpio framework. Performance/latency-wise that would also be strongly encouraged. Tglx isn't super-happy about the chained interrupts at times, as they can create really nasty bugs, but a pure IRQ in fastpath of some kinde is preferable and intuitive either way. Yours, Linus Walleij ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult wrote: > I've been looking for some more direct notification callback for gpio > consumers: here the consumer would register itself as a listener on > some gpio_desc and called back when something changes (with data what > exactly changed, eg. "gpio #3 input switched to high"). > > Seems we currently just have the indirect path via interrupts. I don't know how indirect it is, it seems pretty direct to me. The subsystem was designed in response to how the hardware in front of the developers worked. So far we have had: - Cascaded interrupts - Dedicated (hieararchical) interrupts - Message Signalled Interrupts And if you now bring something else to the show then it's not like the subsystem was designed for some abstract quality such as generic notification of events that occurred, all practical instances have been around actual IRQs and that is why it is using struct irq_chip. What we need to understand is if your new usecase is an outlier so it is simplest modeled by a "mock" irq_chip or we have to design something new altogether like notifications on changes. I suspect irq_chip would be best because all drivers using GPIOs for interrupts are expecting interrupts, and it would be an enormous task to change them all and really annoying to create a new mechanism on the side. Yours, Linus Walleij ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On Sat, Dec 5, 2020 at 9:15 PM Enrico Weigelt, metux IT consult wrote: > The virtio-gpio device/host can raise a signal on line state change. > Kinda IRQ, but not actually running through real IRQs, instead by a > message running though queue. (hmm, kida MSI ? :o). > > I've tried allocating an IRQ range and calling generic_handle_irq(), > but then I'm getting unhanled IRQ trap. This is Bartosz territory, but the gpio-mockup.c driver will insert IRQs into the system, he went and added really core stuff into kernel/irq to make this happen. Notice that in Kconfig it does: select IRQ_SIM Then this is used: include/linux/irq_sim.h This is intended for simulating IRQs and both GPIO and IIO use it. I think this inserts IRQs from debugfs and I have no idea how flexible that is. If it is suitable for what you want to do I don't know but it's virtio so... Yours, Linus Walleij ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
