On 20 Oct 2009, at 3:41 PM, Matze wrote:
From: Jason Nymble <jason.nymble@xxxxxxxxx>
Date: 2009/10/16
Subject: Re: IRQF_TRIGGER on AVR32
To: kernelnewbies <kernelnewbies@xxxxxxxxxxxx> On 16 Oct 2009, at
11:53 AM, Matze wrote:
Hi all,
I'm implementing a device driver on a custom board with AVR32
(AP7000) and I observed that the isr executes on rising edge and
on high state of interrupt pin.
So I tried to request irq like this:
status = request_irq(spiaccel->irq, accel_interrupt,
IRQF_TRIGGER_RISING|IRQF_DISABLED, "accel-driver", spiaccel);
but it does not seem to have any effect on the behaviour on
calling isr.
Is there another place, where the trigger is set globaly?
Is there any possibility to determine inside the isr in which
trigger event it has been executed?
Regards,
Matthias
I'm not familiar with that exact platform, but have done Linux kernel
work on other atmel chips. There is generally a status register
(containing some bits corresponding to interrupt flags) you need to
read, and an interrupt mask register (which has mask bits
corresponding to the interrupts which are actually enabled). You then
do a bitwise AND on the two to determine which bit/s caused the
interrupt. In some cases reading the status register is enough to
clear that particular interrupt on the processor (e.g. bits which are
of the form "indicates event x happened since last time status was
read"), in other case you need to resolve some sort of scenario to
clear the interrupt status (e.g. setup a new peripheral dma
controller
register to point to a dma buffer). If you do not clear the interrupt
condition inside the handler, the handler will be called again
immediately (possibly causing a softlockup), so if there is some
scenario in which you cannot clear the condition you need to disable
that interrupt. Hope some of this rambling helps, even though it
doesn't directly answer your question. AFAIK, you cannot change the
way the interrupt is triggered in the request_irq(), you need to do
that in a processor-specific way using control registers (I might be
wrong about this).
Hi Jason,
thanks for your advices, but I assume reading the registers only
makes sense if your interrupt is bound to an external-interrupt pin
of your processor (PB26 to 28 in my case). Right?
In my case I you as gpio for triggering the interrupt, so I can't
use the register:
/proc # cat interrupts
CPU0
0: 51 intc avr32_comparator
2: 1230 intc dmaca
3: 845357 intc atmel_spi.0
4: 25558 intc atmel_spi.1
5: 0 intc twi
6: 3032 intc ttyS0
22: 812339 intc tc_clkevt
25: 18490 intc eth0
28: 118296 intc mmci
31: 0 intc atmel_usba_udc
115: 0 gpio atmel_mci
145: 25389 gpio accel-driver <-- the interrupt mentioned
154: 730 gpio nanoloc-driver
I tried to read through the kernel source code to understand how
triggers are configured (2.6.25.10):
in kernel/irq/manage.c
request_irq -> calls:
setup_irq -> checks if IRQF_TRIGGER flags are set and calls:
set_type -> callback routine of the intc, which I wasn't able to
locate inside the source tree...
can anyone give me a hint, how a gpio-interrupt will be registered
inside the kernel code?
I realized, that interrupt handling code changed quiet a lot in
newer kernel version (2.6.31). Does anybody know if it's possible to
use the IRQF_TRIGGER flags for gpio-interrupts in there?
Best regards,
Matthias
AFAIK, you need to just read the GPIO pin to clear the interrupt
condition, so this doesn't only apply to the external interrupt pins.
Also, if your ARM also has an AIC (advanced interrupt controller), you
can program that to decide between edge and level triggered.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
