Linux MIPS Architecture development
 help / color / mirror / Atom feed
* Moving from old-irq.c
@ 2001-07-11 12:16 Phil Thompson
  2001-07-12 23:30 ` Ralf Baechle
  0 siblings, 1 reply; 5+ messages in thread
From: Phil Thompson @ 2001-07-11 12:16 UTC (permalink / raw)
  To: 'linux-mips@oss.sgi.com'

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Moving from old-irq.c
  2001-07-11 12:16 Moving from old-irq.c Phil Thompson
@ 2001-07-12 23:30 ` Ralf Baechle
  2001-07-12 23:55   ` Jun Sun
  0 siblings, 1 reply; 5+ messages in thread
From: Ralf Baechle @ 2001-07-12 23:30 UTC (permalink / raw)
  To: Phil Thompson; +Cc: 'linux-mips@oss.sgi.com'

On Wed, Jul 11, 2001 at 01:16:56PM +0100, Phil Thompson wrote:

> 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.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Moving from old-irq.c
  2001-07-12 23:30 ` Ralf Baechle
@ 2001-07-12 23:55   ` Jun Sun
  2001-07-13  0:41     ` Ralf Baechle
  0 siblings, 1 reply; 5+ messages in thread
From: Jun Sun @ 2001-07-12 23:55 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: Phil Thompson, 'linux-mips@oss.sgi.com'

Ralf Baechle wrote:
> 
> On Wed, Jul 11, 2001 at 01:16:56PM +0100, Phil Thompson wrote:
> 
> > 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.
> 
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Moving from old-irq.c
  2001-07-12 23:55   ` Jun Sun
@ 2001-07-13  0:41     ` Ralf Baechle
  2001-07-13  1:04       ` Jun Sun
  0 siblings, 1 reply; 5+ messages in thread
From: Ralf Baechle @ 2001-07-13  0:41 UTC (permalink / raw)
  To: Jun Sun; +Cc: Phil Thompson, 'linux-mips@oss.sgi.com'

On Thu, Jul 12, 2001 at 04:55:27PM -0700, Jun Sun wrote:

> 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?

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Moving from old-irq.c
  2001-07-13  0:41     ` Ralf Baechle
@ 2001-07-13  1:04       ` Jun Sun
  0 siblings, 0 replies; 5+ messages in thread
From: Jun Sun @ 2001-07-13  1:04 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: Phil Thompson, 'linux-mips@oss.sgi.com'

Ralf Baechle wrote:
> 
> On Thu, Jul 12, 2001 at 04:55:27PM -0700, Jun Sun wrote:
> 
> > 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?
> 
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-07-13  1:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-07-11 12:16 Moving from old-irq.c Phil Thompson
2001-07-12 23:30 ` Ralf Baechle
2001-07-12 23:55   ` Jun Sun
2001-07-13  0:41     ` Ralf Baechle
2001-07-13  1:04       ` Jun Sun

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox