Messages in this thread | | | Date | Fri, 22 Jun 2018 23:07:02 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: Nested IRQs resend |
| |
On Sat, 19 May 2018, Sodagudi Prasad wrote: > > Trying to use IRQ resend support with simple driver. I observed that, > re-triggering of nested threaded IRQs is not working. After digging into > "kernel/irq/resend.c" file more, > parent IRQ is needed for re-trigger to work. I could not get much details, > why parent_irq is needed for threaded IRQs resend?
The whole resend stuff was written way before threaded irqs or even nested threaded irqs existed at all.
> 1) Could you please provide more details about resend of nested threaded > IRQs ? > 2) What should be the parent_irq handler in the case of nested IRQs ? > threaded IRQ ? > 3) Are you expecting that parent_irq handler should know pending nesting > IRQs for resend?
Well, the point is that a nested threaded irq runs in the context of some other irq. Ignore the parent irq concept in the resend code as that is completely misleading. That's a corner case which has nothing to do with nested threading at all.
Lets look at how nested threaded irqs work. The thread in which they nest is usually a demultiplexing interrupt of some sort, which looks at a status register to figure out which sub interrupt is pending and then executes that interrupt in its own context. The reason why this is done is because the whole handling of the underlying irq chip needs threaded context and synchronization so running everything from the demultiplex thread makes a lot of things simpler.
But there is no established relationship between the nested irq and the demultiplex irq at least not from the nested irqs point of view. And even if you'd know the irq number of the demultiplex irq and you could resend it, then still you need a way to tell it that you want your particular nested one resent in its context.
The proper solution to this is to actually implement the irq_retrigger() callback for the underlying irq chip. That callback then has to set a software maintained 'pending' bit for the interrupt in question and retrigger the demultiplex interrupt. That works because the irq chip has been populated by the facility which also requested the demultiplex interrupt so the relationship is known there or can be made known easily. Note, that in that case it's not even strictly required to use the resend mechanism for the demultiplex interrupt. The irq chip providing facilty knows that this is a nested thread case so it can simply wake the demultiplex thread via irq_wake_thread().
Hope that helps. If you have further questions, don't hesitate to ask.
Thanks,
tglx
| |