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@kernel.org wrote:
On Fri, 12 May 2023, Marc Zyngier wrote:
On Fri, 12 May 2023 16:39:33 +0100, Charles Keepax ckeepax@opensource.cirrus.com 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