Subject: Moving from old-irq.c

From: Phil Thompson <[email-masked]>
Date: Wed, 11 Jul 2001 13:16:56 +0100

Is there any documentation around that describes how to move from interrupt
code based on old-irq.c to the new code? Or any other hints or suggestions.

Thanks,
Phil

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Jul 2001 01:30:54 +0200

> code based on old-irq.c to the new code? Or any other hints or suggestions.

First disable CONFIG_ROTTEN_IRQ if you were using that and enable
CONFIG_NEW_IRQ.  You'll probably have to hack arch/mips/config.in to do
that.

Next you have to rewrite your systems irq code.  You'll have to provide
an init_IRQ() function to initialize the interrupt system.  As the
absolute minimum it'll have to do something like:

        set_except_vector(0, myasmirqhandler);
        init_generic_irq();

and initialize the entries for all interrupts used by your system in the
irq_desc array like:

        for (i = 0; i < NUM_MY_INTS; i++) {

                irq_desc[i].status      = IRQ_DISABLED;
                irq_desc[i].action      = 0;
                irq_desc[i].depth       = 1;
                irq_desc[i].handler     = handler;
        }

where handler is a pointer to struct like this one:

static struct hw_interrupt_type ip22_my_irq_type = {
        "My interrupt controller",
        startup_my_irq,
        shutdown_my_irq,
        enable_my_irq,
        disable_my_irq,
        mask_and_ack_my_irq,
        end_my_irq,
        NULL
};

All that's left now is to write the function references in above struct
initialization:

static void enable_my_irq(unsigned int irq)
{
	/* enable the interrupt in the controller  */
}

static unsigned int startup_my_irq(unsigned int irq)
{
        enable_my_irq(irq);

        return 0;               /* Never anything pending  */
}

static void disable_my_irq(unsigned int irq)
{
	/* Disable function in the interrupt controller  */
}

static void shutdown_my_irq(unsigned int irq)
{
	/*
	 * Disable interrupt in the interrupt controller.  Often this function
	 * is identical to disable_my_irq.
	 */
}

static void mask_and_ack_my_irq(unsigned int irq)
{
	/*
	 * Mask and acknowledge interrupt.  Often this function is identical
	 * to disable_my_irq.  Exception is for example the i8259 PICs.
	 */
}

static void end_my_irq (unsigned int irq)
{
        if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
                enable_my_irq(irq);
}

Take a look at arch/mips/sgi/indy_int.c but there are more examples.

The plan is to nuke old-irq.c early in 2.5; at the same time also something
like arch/{i386,mips}/kernel/irq.c will become kernel/irq.c.

  Ralf

---

From: Jun Sun <[email-masked]>
Date: Thu, 12 Jul 2001 16:55:27 -0700

> Take a look at arch/mips/sgi/indy_int.c but there are more examples.

Under ddb5xxx/ directory there is an example of doing cascading portable IRQ
controllers.  The irq_cpu.c file really should be shared by all common r4k
style CPUs.

> You'll have to provide
> an init_IRQ()

Ralf, I think we should have a common init_IRQ() in arch/mips/kernel, which
will then call (*setup_irq)().  This way it is easier to build a kernel for
multiple boards.  It is also more compatible with the current arrangment. 
What do you think?

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Jul 2001 02:41:08 +0200

> multiple boards.  It is also more compatible with the current arrangment. 

Well, do you actually build kernels for multiple boards that need this?  In
practice pretty much nobody seems to be interested; technical problems also
makes this much harder than on other architectures, for example of all my
MIPS systems none could actually share a kernel.

  Ralf

---

From: Jun Sun <[email-masked]>
Date: Thu, 12 Jul 2001 18:04:17 -0700

Ralf Baechle wrote:
> Well, do you actually build kernels for multiple boards that need this?  

The answer is actually yes.  

What is happening in embedded world is people often derive their boards from
another board (probably reference board).  Sometimes the difference between
those two boards are very small (but still have difference such as in
interrupt routing).  It will then become interesting to share most of the code
and leave some other code hookable.

Another scenario is sometimes vendors builds a base board which can plug in
multiple different daughter boards.  In many cases it is desirable to build
one kernel for the same "base board".

That is the need I have seen so far. 

Jun