This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Interrupt handling and Device Drivers.


>>>>> "Satish" == Satish Nayak <nayak@sasi.com> writes:

Satish> Hi, I have following questions.

Satish> It was clear from the documentation that with every device
Satish> driver there exists an init function which possibly might do
Satish> the following things : 1. Initialize the device 2. perform h/w
Satish> setup 3 Create interrupt 4. Hook an interrupt handler.  and so
Satish> on.

Satish> Is there any cleanup function associated with device driver ?
Satish> How does any device gets de-initialized ?

The current driver scheme doesn't have a cleanup-part.

It's not obvious to me that it would be necessary to change drivers in
an embedded system.  But I guess something may be required for
PCMCIA(?) or other hot-pluggable interfaces.

This may be something that's being considered as part of the ELIX
initiative. I don't know.

Satish> My second query is about interrupt handling.  When more than
Satish> one isr exists for a given vector (I hope this is done through
Satish> interrupt chaining ), what part of the kernel code calls those
Satish> isrs? It is understandable that in vectors.s the IRQ handler
Satish> will call the first handler in the chain. Correct me if I am
Satish> incorrect.

You can only have one ISR per vector unless you (a) enable interrupt
chaining (which would have a glabal effect on the way interrupts are
handled), or (b) attach a small handler which takes care of chaining
on that particular vector.

Satish> My third query is about the handling of IRQ exception handler.
Satish> During handling of IRQ I observed the following steps in vectors.s
Satish> 
Satish> 1 In handle_IRQ_or_FIQ switch mode to supervisor and disable irq and
Satish> fiq.
Satish> 2 Switch the stack if required based on irq_level.
Satish> 3 Lock the scheduler
Satish> 4 Decode the interrupt source using hal_IRQ_handler.
Satish> 5 Call the interrupt handler pertaining to the above decoded vector.
Satish> 6 Call interrupt_end.
Satish> 
Satish> Now why do we need to disable the irq and fiq again before following two
Satish> 
Satish> instructions.
Satish> 
Satish>  ldr lr,[ip,#armreg_lr]
Satish>  ldr sp,[sp,#armreg_sp]
Satish> 
Satish> Are not they disabled in step 1 above?

interrupt_end may reenable interrupts.

Satish> 
Satish> And next few instructions will bring the processor back into the IRQ
Satish> mode.
Satish> 
Satish> bic r0,r0,#CPSR_MODE_BITS
Satish> orr r0,r0,#CPSR_IRQ_MODE
Satish> msr cpsr,r0

Hm, let's see. Application threads run in supervisor mode in eCos. The
code here needs to switch to that mode as an atomic operation,
updating all the necessary registers. Switching to interrupt mode and
setting spsr/lr lets us do that using 'movs'.

The current implementation works with all the ARM and Thumb boards we
have tested it on. Some of the code may seem a bit, um, strange. But
this is something that has been discussed before on this list.

I'm sure that if you were to submit a rewrite which optimizes the
critical path of interrupts (and also works on all the supported
boards) we'd be happy to integrate it :)

Jesper

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]