On Tue, May 16, 2023 at 11:09:36AM +0100, Lee Jones wrote: > On Tue, 16 May 2023, Marc Zyngier wrote: > > On Mon, 15 May 2023 12:25:54 +0100, > > Lee Jones <lee@xxxxxxxxxx> wrote: > > > On Fri, 12 May 2023, Marc Zyngier wrote: > > > > On Fri, 12 May 2023 16:39:33 +0100, > > > > Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > I'm not aware of another subsystem that deals with !IRQChip level IRQ > > > controllers. Where do simple or "second class" interrupt controllers > > > go? > > > > This isn't an interrupt controller. This is internal signalling, local > > to a single component that has been artificially broken into discrete > > bits, including an interrupt controller. The only *real* interrupts > > here are the GPIOs. > > I would question this statement a little, they are fixed function IRQs sure but they are still real interrupts. These are lines which receive a signal and on an edge they set a stick status bit, which causes another signal to generate an edge, they have registers which let you mask events, if it walks like a duck and all. The only difference between this and a "real" interrupt is whether the chip designer or the board designer was the person who decided where the wire was connected. > > I'm happy to see an interrupt controller for the GPIOs. But the rest > > is just internal muck that doesn't really belong here. Where should it Internal-ish, granted many of them are primarily useful to the device itself. But it is very easy to construct situations where say knowing the speaker thermals are high, or that a jack has been inserted are useful outside of the CODEC driver itself. > > go? Together with the rest of the stuff that manages the block as a > > whole. Which looks like the MFD subsystem to me. > > Very well. Let's see this "muck" in a patch please! Groovy I will do a re-spin moving the IRQ stuff to the MFD and lets see where we get to. Thank you all for your help in reviewing this so far. Thanks, Charles
