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
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ