> On 20 Mar 2024, at 16:00, Peter Maydell <peter.mayd...@linaro.org> wrote: > > WARNING: This email originated from outside of Qualcomm. Please be wary of > any links or attachments, and do not enable macros. > > 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. >
Yeah - makes sense. Cheers Mark. > 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