On Wed, 20 Mar 2024 at 14:10, Mark Burton <mburton@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.)