generic irq handler and stack?

generic irq handler and stack?

[Tim Sander]

Hi

The interrupt handling on the i.mx35x seems to handle only one interrupt at a 
time. This generates larger then nessecary interrupt jitter. I am currently 
investigating to reprogram the AVIC to enable higher priority interrupts to 
interrupt lower priority interrupts. The mechanism is outlined in section 
13,3.8 of the IMX35 Reference Manual.

I thought about implementing the reprogramming of the AVIC in the 
ack() and end() callbacks. The problem is that i need to push the current 
priority on the stack but that doesn't seem to be possible with the generic 
irq subsystem? Do i need to implement the whole irq handler or is there some 
other way?

Thanks
Tim

Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich fur den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.

generic irq handler and stack?

[Russell King - ARM Linux]

On Tue, Dec 07, 2010 at 11:29:26AM +0100, Tim Sander wrote:
> The interrupt handling on the i.mx35x seems to handle only one interrupt at a 
> time. This generates larger then nessecary interrupt jitter. I am currently 
> investigating to reprogram the AVIC to enable higher priority interrupts to 
> interrupt lower priority interrupts. The mechanism is outlined in section 
> 13,3.8 of the IMX35 Reference Manual.

The kernel now runs _all_ interrupts with IRQs masked on the CPU.  See
e58aa3d2d0cc01ad8d6f7f640a0670433f794922.

generic irq handler and stack?

[Tim Sander]

Hi

> > The interrupt handling on the i.mx35x seems to handle only one interrupt
> > at a time. This generates larger then nessecary interrupt jitter. I am
> > currently investigating to reprogram the AVIC to enable higher priority
> > interrupts to interrupt lower priority interrupts. The mechanism is
> > outlined in section 13,3.8 of the IMX35 Reference Manual.
> 
> The kernel now runs _all_ interrupts with IRQs masked on the CPU.  See
> e58aa3d2d0cc01ad8d6f7f640a0670433f794922.
Thanks Russell for your  quick answer. But as far as i understand this is only
one step to get better interrupt latency on i.mx35x since the AVIC by default
only allows one interrupt at a time. So any idea which is the cleanest way to 
push the SPSR_irq register on the stack. I am currently a little lost between 
the common code, the arm and platform specific code, so any hint is welcome.

Thanks
Tim

Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich f?r den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.

generic irq handler and stack?

[Russell King - ARM Linux]

On Tue, Dec 07, 2010 at 01:56:16PM +0100, Tim Sander wrote:
> Hi
> 
> > > The interrupt handling on the i.mx35x seems to handle only one interrupt
> > > at a time. This generates larger then nessecary interrupt jitter. I am
> > > currently investigating to reprogram the AVIC to enable higher priority
> > > interrupts to interrupt lower priority interrupts. The mechanism is
> > > outlined in section 13,3.8 of the IMX35 Reference Manual.
> > 
> > The kernel now runs _all_ interrupts with IRQs masked on the CPU.  See
> > e58aa3d2d0cc01ad8d6f7f640a0670433f794922.
>
> Thanks Russell for your  quick answer. But as far as i understand this is only
> one step to get better interrupt latency on i.mx35x since the AVIC by default
> only allows one interrupt at a time. So any idea which is the cleanest way to 
> push the SPSR_irq register on the stack.

We don't run interrupts in IRQ mode.  The exception is entered in IRQ
mode, but we then save what state is necessary and switch to SVC mode.

We have supported nested interrupts since the 1.x kernel days - there's
no code changes needed to support having one interrupt handler interrupt
another handler - merely re-enabling interrupts in your own handlers
will allow it to happen if your IRQ controller will also allow it.

generic irq handler and stack?

[Tim Sander]

Hi Russell
> We don't run interrupts in IRQ mode.  The exception is entered in IRQ
> mode, but we then save what state is necessary and switch to SVC mode.
Ok. So e58aa3d2d0cc01ad8d6f7f640a0670433f794922 probably doesn't add any
additional delays in this case.

> We have supported nested interrupts since the 1.x kernel days - there's
> no code changes needed to support having one interrupt handler interrupt
> another handler - merely re-enabling interrupts in your own handlers
> will allow it to happen if your IRQ controller will also allow it.
Well the AVIC of the i.mx35x is not supporting multiple parallel handlers by 
default, but with some extra steps taken from the reference manual which i 
attached below this should be possible. Most of this stuff would go into the 
generic ack() and end() handlers but i don't know what to to with the NIMASK 
value, which should be pushed onto the stack (step 3 below). Beeing in a 
subroutine ( ack() )  it obviously doesn't make sense to push it on the stack 
there. So my question is: is there a nice way to implement the steps below 
within the generic interrupt handler infrastructure?

Thanks
Tim

PS: The steps:
1. Push the link register (LR_irq) on to the stack (SP_irq) i.MX35 (MCIMX35) 
2. Push the saved status register (SPSR_irq) on to the stack
3. Read the current value of NIMASK and push this value on to the stack
4. Read current priority level via NIVECSR
5. Interrupts of the equal or lesser priority than the current priority level 
should be masked via the NIMASK register by writing value from NIVECSR
6. Clear the I bit in the ARM1136JF-S core via a MSR / MRS command sequence 
(now a higher priority normal interrupt can preempt a lower priority one)
Also change the operating mode of the core to System Mode from IRQ mode
7. Push System Mode link register (LR) on to the stack (SP_user)
8. The traditional interrupt service routine is now included
9. Pop System Mode link register (LR) from the stack (SP_user)
10. Set I bit in the ARM1136JF-S core via a MSR / MRS command sequence (thus 
disabling all normal interrupts)
Also change the operating mode of the core to IRQ Mode from System mode
11. Pop the original value of normal interrupt mask and write to the NIMASK 
register
12. The saved status register should be popped from the stack (SP_irq)
13. The link register should be popped from the stack into the PC
14. Return from nIRQ

Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich f?r den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.

generic irq handler and stack?

[Russell King - ARM Linux]

On Wed, Dec 08, 2010 at 09:54:13AM +0100, Tim Sander wrote:
> Hi Russell
> > We don't run interrupts in IRQ mode.  The exception is entered in IRQ
> > mode, but we then save what state is necessary and switch to SVC mode.
> Ok. So e58aa3d2d0cc01ad8d6f7f640a0670433f794922 probably doesn't add any
> additional delays in this case.

I fail to see what has that commit ID got to do with whether we run IRQ
handlers in IRQ mode or SVC mode.

Interrupt latencies on i.mx was Re: generic irq handler and stack?

[Tim Sander]

Hi
> > Ok. So e58aa3d2d0cc01ad8d6f7f640a0670433f794922 probably doesn't add any
> > additional delays in this case.
> I fail to see what has that commit ID got to do with whether we run IRQ
> handlers in IRQ mode or SVC mode.
My focus was on interrupt service latencies but i might still be confused 
about the interrupt system...

Nevertheless to answer my question and make people happy searching the 
archives: The answer to my question where to put specific interrupt controller 
code on the arm freescale mxc (i.mx) platform is the entry-macro.S to be  
found under arch/arm/plat-mxc/include/mach. So i also found out that the 
switch CONFIG_MXC_IRQ_PRIOR seems to handle the AVIC in the way it is 
described in the reference manual (At least if r4 is saved on stack after
"get_irqnr_preamble" and restored before "get_irqnr_and_base".). 

Nevertheless if i am enabling MXC_IRQ_PRIOR and set the priorities like this 
in platform init:
    imx_irq_set_priority(34,15); //SDMA Measval
    imx_irq_set_priority(29,14); //TIMER
    imx_irq_set_priority(57,13); //FEC
I get worse IRQ latency times (ca. 90?s vs. ca. 45?s) when MXC_IRQ_PRIOR is 
switched *on* and flood pinging the device. This result seems at least counter
intuitive to me. 

Besides, wouldn't it be usefull to allow priority setting even if       
MXC_IRQ_PRIOR is not set? As far as i understand the code with MXC_IRQ_PRIOR 
the IRQ's are not nested. This means if one interrupt finishes the next one is 
picked, so the priority set with imx_irq_set_priority would determine which 
interrupt is picked next when two interrupts are pending concurrently? 

Best regards
Tim

Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 

Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster

Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich f?r den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.

generic irq handler and stack?

[Ben Dooks]

On 07/12/10 12:56, Tim Sander wrote:
> Hi
> 
> Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com 
> 
> Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147  
> Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster
> 
> Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147 
> Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster
> 
> The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Hi, I'm not the intended addresse but I can't be bothered to
delete the email.

Disclaimers on emails to lists like these just annoy people as
they're useless for public information, and probably difficult
or impossible to enforce in many jurisdictions.