Handle interrupts doubt.

LEICIF · 01-14-2010, 05:01 AM

Hello,

I am trying to use a interrupt but it does not work fine.

This is my driver code:

Code:

#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/module.h>
#include <linux/interrupt.h>
#include <asm/io.h>
#include <linux/time.h>
#include <linux/ioport.h>
#include <linux/signal.h>
#include <linux/fcntl.h>
#include <linux/fs.h>

#define	INTERRUPT_10	10
#define	INTERRUPT_15	15

unsigned int contador;
unsigned int contador1;

irq_handler_t handler_10(void)
{
	contador1++;
	printk("Interrupcion %d ejecutada %d.\n", INTERRUPT_10, contador1);
	return 0;
}

irq_handler_t handler_15(void)
{
	contador++;
	printk("Interrupcion %d ejecutada %d.\n", INTERRUPT_15, contador);
	return 0;
}

int xinit_module(void)
{
int ret;

	contador = 0;
	contador1 = 0;
	// Request IRQ 10
        ret = request_irq(INTERRUPT_10, (irq_handler_t) handler_10, IRQF_DISABLED, "LEICIF_10", NULL);
	if (ret < 0)
	{
		printk("Error, can not request irq %d", INTERRUPT_10);	
		return (ret);
	}
	enable_irq(INTERRUPT_10);

	// Request IRQ 15
        ret = request_irq(INTERRUPT_15, (irq_handler_t) handler_15, IRQF_DISABLED, "LEICIF_15", NULL);
	if (ret < 0)
	{
		printk("Error, can not request irq %d", INTERRUPT_15);	
		return (ret);
	}
	enable_irq(INTERRUPT_15);

        printk("wait for interrupt\n");
        printk("return code %d \n", ret);
        return 0;
}

void xcleanup_module(void)
{
        disable_irq(INTERRUPT_10);
        free_irq(INTERRUPT_10, NULL);
        disable_irq(INTERRUPT_15);
        free_irq(INTERRUPT_15, NULL);
        printk("closed\n");
}

module_init(xinit_module);
module_exit(xcleanup_module);

MODULE_LICENSE("GPL");

Then I connect INT10 and INT15 to square wave but nothing happen.

Quote:

# cat /proc/interrupts
CPU0
0: 39466 XT-PIC-XT timer
1: 3 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 1 XT-PIC-XT
4: 2 XT-PIC-XT
6: 2 XT-PIC-XT floppy
8: 0 XT-PIC-XT rtc
9: 0 XT-PIC-XT acpi
10: 0 XT-PIC-XT LEICIF_10
11: 787 XT-PIC-XT ehci_hcd:usb1, ohci_hcd:usb2, eth0
12: 3 XT-PIC-XT i8042
14: 752 XT-PIC-XT ide0
15: 0 XT-PIC-XT LEICIF_15
NMI: 0 Non-maskable interrupts
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0

I have checked code several times but I do not understand what is the problem.

Any advice??
Best regards

Aquarius_Girl · 01-14-2010, 05:29 AM

Have a look at this,

http://www.linuxquestions.org/questi...inux-763595/#4

here I had written an interrupt handler w.r.t serial port RS232

See if it helps you in some way !!

LEICIF · 01-15-2010, 05:36 AM

Hello,

Well I have made a change in bios and it works but I do not understand it.

For example, my driver use interrupt line 5 and 10, right?
If I request_irq() there is not problem, but nothing happen when interrupt trigger.

But later,I changed in BIOS that irq line 5 and 10 are RESERVE, and now my driver works fine, and execute interrupt handler when interrupt trigger.

Then, my question is, what is the difference if I reserve irq in bios??

Without changes in BIOS, can I make something in Linux to reserve irqs???

Best regards

Aquarius_Girl · 01-15-2010, 05:51 AM

Quote:

For example, my driver use interrupt line 5 and 10, right?

For what hardware do interrupt line 5 and 10 stand for ?

Quote:

But later,I changed in BIOS that irq line 5 and 10 are RESERVE, and now my driver works fine, and execute interrupt handler when interrupt trigger.

Would u show how did u do it !

Any way I don't think it is advisable to change things in BIOS like u did !

LEICIF · 01-15-2010, 06:32 AM

Quote:

Originally Posted by anishakaul

For what hardware do interrupt line 5 and 10 stand for ?

Would u show how did u do it !

Any way I don't think it is advisable to change things in BIOS like u did !

Hello,

irq lines 5 and 10 is not for standard hardware. I have a voltage monitoring in my embedded system and when voltage is under or above a value, this IC send signals that I connect to irq5 (low voltage) and irq10 (high voltage).
My driver execute interrupt handler for both irqs and send signal to user space, where is my user program.

In BIOS:

PnP/PCI Configurations->Resources controlled by [MANUAL]
->IRQ Resouces->IRQ-5 assigned to [Legacy ISA]
->IRQ-10 assigned to [Legacy ISA]

With this changes interrupts trigger.

Best regards.

Aquarius_Girl · 02-04-2010, 05:03 AM

Quote:

For example, my driver use interrupt line 5 and 10, right?
If I request_irq() there is not problem, but nothing happen when interrupt trigger.

But later,I changed in BIOS that irq line 5 and 10 are RESERVE, and now my driver works fine, and execute interrupt handler when interrupt trigger.

Then, my question is, what is the difference if I reserve irq in bios??

See if the following link helps:

http://linux.about.com/od/pap_howto/a/hwtpap04t02.htm

sundialsvcs · 02-04-2010, 07:21 PM

IRQs are like something that you have probably never seen or heard of: a telephone "party line."

In the early days, when there were not enough telephone wires to go around, many houses were hooked up to the same telephone circuit. So, when the phone rang, it might not be for your house. You had to listen for a distinctive pattern of rings that told you whether or not the call was for you.

If it was, then you picked up the phone and talked.
If it wasn't, you picked up the phone anyway so that you could snoop on your neighbors.

When an IRQ occurs, your driver still has to check the hardware device to see if it was actually the one that presented the interrupt. Maybe it was, or maybe the interrupt came from "someone else on the same line."

The idea of "reserving interrupts" comes from Plug-n-Play. Most devices these days can use any IRQ line, and so they have to be told which one to use. Plug-N-Play does all that: it locates devices, assigns IRQs to them, and tells them which IRQ to use.

But if (older) devices are hard-wired to use only a particular IRQ, and their (also, older) device drivers are also dependent on that, then the BIOS may have to be told to "reserve" the IRQ so that it does not get auto-assigned to a Plug-N-Play capable device. (Older drivers and/or hardware might not be smart enough to handle "someone else calling on the same line ...")