On Wed, 20 Mar 2024 at 14:10, Mark Burton <mbur...@qti.qualcomm.com> wrote: > I’d broaden this to all ’signals’ (IRQ, Reset etc) - and I guess > similar statements apply, with the “bridge” between the function > and the GPIO mechanism moved closer or further from the originator(s) > of the activity. > > The issue isn’t my “machine” model, rather the compose-ability of > (any) such machine. A-priori, a model writer doesn’t know if they > should respond directly to an NMI or not - Hence they dont know if > they should implement the TYPE_NMI or not. That’s a decision only > the machine composer knows. > My suggestion would be to use a GPIO interface to models, which can > then be appropriately wired. (And, hence, to have a single place > that implements the TYPE_NMI interface and provides the GPIO wire > ready for wiring to appropriate devices).
I feel like that's a long way in the future, but my back-of-the-envelope design sketch of that is that the TYPE_MACHINE class that's implementing the "I am just a container for all the devices that the user has specified and wired together" machine would itself implement TYPE_NMI and when an NMI came in it would assert a GPIO line that the user could wire up, or not wire up, as they chose. Right now we can't do that though, because, among other reasons, TYPE_MACHINE isn't a TYPE_DEVICE. (I do want to fix that, though: I'm hoping it won't be too difficult.) thanks -- PMM
