linuxsh-dev

Problem with IRQ0 in SH7705

[Cmmn Ml <cm...@ya...>]

Hello,
   
  This may not be something interesting to the general community, because SH7705 is not now widley used. But if someone can give some thoughts, it will be a great help for me.
  
I'm working on SH 7705 Solution Engine board, my kernel is linux 2.6.16 (after applying the SH linux stable patch relavant to this kernel version sh--stable--2.6.16). Currently I'm developing a driver which hanldes interrupt coming from IRQ0 processor pin. When I try to register the interrupt handler, I get an error message saying "irq event 32: bogus return value 7". The way I try to register the interrupt is 
   
   if(request_irq(32, interrupt_handler, SA_INTERRUPT, "IRQ0_INT", NULL) == 0)
 {
         printk("interrupt_handler registered\r\n"); 
  }
   
  When this code is executed, request_irq returns with 0 indicating success, but then it gives up the message ""irq event 32: bogus return value 7". When the interrupt comes, the execution goes into the interrupt handler as well.
   
  The value 32 is the irq number I'm requesting (which is relevent to IRQ0) and I don't know what is 7. FYI : I'm setting the priority of IRQ0 as 7 in IPRC register.
   
  Were there any known problems in 2.6.16 kernel with IRQ0 in 7705, If anyone can give some thoughts on this, it'll be a great.
   
  Thanks in advance.
   
  Cmmn Ml

       
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
 Play Sims Stories at Yahoo! Games. 

Re: Problem with IRQ0 in SH7705

[Paul M. <le...@li...>]

On Wed, Oct 03, 2007 at 07:32:39AM -0700, Cmmn Ml wrote:
>    I'm working on SH 7705 Solution Engine board, my kernel is linux 2.6.16
>    (after applying the SH linux stable patch relavant to this kernel
>    version sh--stable--2.6.16). Currently I'm developing a driver which
>    hanldes interrupt coming from IRQ0 processor pin. When I try to
>    register the interrupt handler, I get an error message saying "irq
>    event 32: bogus return value 7". The way I try to register the
>    interrupt is
>
>    When this code is executed, request_irq returns with 0 indicating
>    success, but then it gives up the message ""irq event 32: bogus return
>    value 7". When the interrupt comes, the execution goes into the
>    interrupt handler as well.
> 
There are a couple of reasons you might get this message, and it all
relates to your IRQ handler. Your IRQ handler needs to return one of
IRQ_NONE (if it's not handling it) or IRQ_HANDLED, this printk gets
triggered if either a) your irqreturn_t is some bogus value, or b) the
IRQ is stuck.

As you didn't post the backtrace after that printk, it's difficult to
determine what the originating call path was. In the event that the IRQ
is stuck (ie, "99,900 of the previous 100,000 interrupts have not been
handled"), this will also trigger. So you might also have an issue with
the IRQ not being acked properly.

Re: Problem with IRQ0 in SH7705

[Cmmn Ml <cm...@ya...>]

Hello Paul,
   
  Thanks for pointing me where the problem is, I found my problem with the return value and got it fixed. Thanks again for your kind reply.
   
  Cmmn Ml
  

Paul Mundt <le...@li...> wrote:
  On Wed, Oct 03, 2007 at 07:32:39AM -0700, Cmmn Ml wrote:
> I'm working on SH 7705 Solution Engine board, my kernel is linux 2.6.16
> (after applying the SH linux stable patch relavant to this kernel
> version sh--stable--2.6.16). Currently I'm developing a driver which
> hanldes interrupt coming from IRQ0 processor pin. When I try to
> register the interrupt handler, I get an error message saying "irq
> event 32: bogus return value 7". The way I try to register the
> interrupt is
>
> When this code is executed, request_irq returns with 0 indicating
> success, but then it gives up the message ""irq event 32: bogus return
> value 7". When the interrupt comes, the execution goes into the
> interrupt handler as well.
> 
There are a couple of reasons you might get this message, and it all
relates to your IRQ handler. Your IRQ handler needs to return one of
IRQ_NONE (if it's not handling it) or IRQ_HANDLED, this printk gets
triggered if either a) your irqreturn_t is some bogus value, or b) the
IRQ is stuck.

As you didn't post the backtrace after that printk, it's difficult to
determine what the originating call path was. In the event that the IRQ
is stuck (ie, "99,900 of the previous 100,000 interrupts have not been
handled"), this will also trigger. So you might also have an issue with
the IRQ not being acked properly.


       
---------------------------------
 Check out  the hottest 2008 models today at Yahoo! Autos.

Re: Problem with IRQ0 in SH7705

[Magnus D. <mag...@gm...>]

Hi there,

On 10/3/07, Cmmn Ml <cm...@ya...> wrote:
> This may not be something interesting to the general community, because
> SH7705 is not now widley used. But if someone can give some thoughts, it
> will be a great help for me.

[snip]

> The value 32 is the irq number I'm requesting (which is relevent to IRQ0)
> and I don't know what is 7. FYI : I'm setting the priority of IRQ0 as 7 in
> IPRC register.
>
> Were there any known problems in 2.6.16 kernel with IRQ0 in 7705, If anyone
> can give some thoughts on this, it'll be a great.

I recommend you to use a more recent kernel to begin with. Many things
have changed since 2.6.16.

I suspect that older kernels didn't provide any masking and unmasking
code for IRQ0. There is at least no such code in this old version:

http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=blob;f=arch/sh/kernel/cpu/sh3/setup-sh7705.c;h=a55b8ce2c54c46e156319f674928e36f07bd7f15;hb=68abdbbb03476a60d932eeba0035dd5069afec38

There may be some board specific code that handles IRQ0 though, I'm
not sure. But anyway, you need some code that masks and unmasks IRQ0
in IPRC. There is no IRQ0 interrupt in ipr_irq_table above so I
suspect it is not supported in older kernels. The new intc tables
should support that interrupt source out of the box though.

Hope this helps!

/ magnus