Thread (14 messages) 14 messages, 4 authors, 2025-02-19

Re: [RFC PATCH 1/2] irqchip: ti-tsir: Add support for Timesync Interrupt Router

From: Vankar, Chintan <hidden>
Date: 2025-02-19 19:36:27
Also in: lkml

Hello Thomas/Greg,

On 2/18/2025 1:47 AM, Thomas Gleixner wrote:
Chintan!

On Sat, Feb 15 2025 at 17:19, Chintan Vankar wrote:
quoted
On 14/02/25 04:13, Thomas Gleixner wrote:
quoted
Two questions:

   1) For the case where no interrupt is involved, how is the routing
      configured?

   2) For the case where it routes an input line to an interupt, then how
      is this interrupt going to be handled by this interrupt domain which
      is not connected to anything and implements an empty disfunctional
      interrupt chip?
For both the cases above the job of Timesync INTR is to map the output
register with the corresponding input.

As described in section 11.3.2.1 in the TRM at:
https://www.ti.com/lit/ug/spruiu1d/spruiu1d.pdf,
the job of the Timesync INTR is to provide a configuration of the
"output registers which controls the selection". Hence we just have to
provide configuration APIs in the Timesync INTR which programs output
registers of the Timesync INTR. About the handling of the interrupts,
the device which receives an interrupt needs to handle the interrupt.

Could you please explain why we consider these two cases to be
different?
They are different as

   #1 Routes the signal from one IP block to another IP block

      So there is no notion of an actual interrupt, but still you use the
      interrupt domain mechanism, which requires to allocate a Linux
      interrupt number just to configure that router.

      What's the purpose of this interrupt number and the allocated
      resources behind it?

   #2 Routes the signal from an IP block to an actual interrupt "input"

      Again, this requires to allocate a Linux interrupt number which is
      disfunctional as it is not connected in the interrupt domain
      hierarchy and just provides an interrupt chip with a name and no
      actual functionality behind it.

      So the resulting real interrupt needs yet another interrupt number
      which then maps to something which actually can handle interrupts.

So in some aspect they are not that different because both have nothing
to do with the actual concept of interrupt management in the Linux
kernel.

 From the kernel's interrupt handling POV this is a completely
transparent piece of hardware, which is not associated to any interrupt
handling mechanism. Just because the manual mentions INTR in the name of
the IP block does not make it part of the actual kernel interrupt
handling.

I have no idea into which subsystem such a SoC configuration belongs to,
but Greg might have an idea.
Thanks for the reviewing the patch. Since you suggest to implement it
with a different subsystem, I want your and Greg's suggestion for that.

As we discussed and also from the documentation, Timesync INTR should be
configured by programming it's output registers to control the selection
corresponding to the input. Mux-controller subsystem also works on the
similar kind of principle, to program the output by selectively choosing
from multiple input sources, I am trying to relate Timesync INTR with
that subsystem.

Could you please suggest if the implementation can be achieved using the
mux-subsystem ?


Regards,
Chintan.
Thanks,

         tglx
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help