gpio irq in omap 4460

Hi,

GPIO_155 belongs to the GPIO5 submodule, so you will need to clear the irq status bit on that module. For more info look at TRM chapter 25 General-Purpose Interface

Regards!

ICe

---------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
---------------------------------------------------------------------------------------------------------

Hi ICe,

Thanks for the reply.

I am trying to use the register GPIO_IRQSTATUS_0 (0x4805 B02C) to clear the IRQ status of pin 155.

I am not sure if I can use this register.

When I clear the status bit like,

irqstatus=ioremap(0x4805B02C, sizeof(unsigned int));

iowrite32((1<<(155%32)),irqstatus);

at the function call iowrite32 , Iam getting an exception.

Even I tried using GPIO_IRQSTATUS_CLR_0 also.But still I am getting the following exception.

Please let me know If I miss anything here.

[ 1072.206115] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:135 l3_interrupt_h)
[ 1072.215667] CUSTOM SRESP error with SOURCE:L4 PER2                           
[ 1072.220916] Modules linked in: vfsspidrv [last unloaded: vfsspidrv]          
[ 1072.228179] Backtrace:                                                       
[ 1072.231048] [<c0050980>] (dump_backtrace+0x0/0x10c) from [<c05413d4>] (dump_)
[ 1072.240112]  r7:00000009 r6:00000087 r5:c0070094 r4:c0703de8                 
[ 1072.247070] [<c05413bc>] (dump_stack+0x0/0x1c) from [<c0090974>] (warn_slowp)
[ 1072.256774] [<c0090920>] (warn_slowpath_common+0x0/0x6c) from [<c0090a30>] ()
[ 1072.267059]  r9:c0789a44 r8:f0834b00 r7:00080003 r6:c0730d68 r5:00000b48     
[ 1072.274810] r4:f0834000                                                      
[ 1072.278076] [<c00909f8>] (warn_slowpath_fmt+0x0/0x40) from [<c0070094>] (l3_)
[ 1072.288543]  r3:c0673f2c r2:c0673e30                                         
[ 1072.292907] [<c006fe38>] (l3_interrupt_handler+0x0/0x34c) from [<c00d3cf0>] )
[ 1072.303833] [<c00d3c9c>] (handle_irq_event_percpu+0x0/0x188) from [<c00d3e68)
[ 1072.314422] [<c00d3e24>] (handle_irq_event+0x0/0x64) from [<c00d662c>] (hand)
[ 1072.324523]  r7:0000002a r6:c0702000 r5:c0705b8c r4:c0705b40                 
[ 1072.331359] [<c00d658c>] (handle_fasteoi_irq+0x0/0x10c) from [<c00d3858>] (g)
[ 1072.341705]  r5:c0044e80 r4:c0714568                                         
[ 1072.345977] [<c00d381c>] (generic_handle_irq+0x0/0x48) from [<c0046054>] (as)
[ 1072.355468] [<c0046000>] (asm_do_IRQ+0x0/0xb4) from [<c004c4c8>] (__irq_svc+)
[ 1072.363952] Exception stack(0xc0703ee0 to 0xc0703f28)                        
[ 1072.369567] 3ee0: c0703f28 3b9aca00 466fcd5b 00000000 c0edf100 c0703f28 a2e69
[ 1072.378387] 3f00: a302e35b 000000f9 00000000 c0703f5c fffffff1 c0703f28 c0070
[ 1072.387329] 3f20: 90000113 ffffffff                                          
[ 1072.391265]  r9:c0702000 r8:00000001 r7:00000002 r6:0000002a r5:fa240100     
[ 1072.398986] r4:ffffffff                                                      
[ 1072.402252] [<c00637f0>] (omap4_enter_idle_wfi+0x0/0xdc) from [<c035b0d8>] ()
[ 1072.412689]  r9:412fc09a r8:8000406a r7:c071be14 r6:c07ccc44 r5:c0edf110     
[ 1072.420440] r4:c0edf100                                                      
[ 1072.423706] [<c035b03c>] (cpuidle_idle_call+0x0/0x130) from [<c004dfb0>] (cp)
[ 1072.433105]  r9:412fc09a r8:8000406a r6:c054ae44 r5:c07619c4 r4:c0702000     
[ 1072.441009] [<c004deec>] (cpu_idle+0x0/0x104) from [<c0537304>] (rest_init+0)
[ 1072.449554]  r7:00000000 r6:c003955c r5:00000000 r4:c0702000                 
[ 1072.456451] [<c0537264>] (rest_init+0x0/0xa4) from [<c000896c>] (start_kerne)
[ 1072.465301]  r5:00000000 r4:c07143dc                                         
[ 1072.469696] [<c00086c4>] (start_kernel+0x0/0x2fc) from [<8000803c>] (0x80008)
[ 1072.477691] ---[ end trace 4dab73311341e9a5 ]---                    

Thanks in advance.

Regards,

Sunil.

Hi Sunil,

Are you sure it crash when cleaning the bit?, it seems to me that it fails when it is interrupting.

L3 is detecting an error on L4 PER, I am not sure what it could be without the code.

Tip: Make sure the GPIO5 module has a clock running

Also checking with some partners with more experience on irq, they said that the ioremap shouldn't be inside the isr, it is preferable to store the value in the probe on somewhere else before irq.

Also maybe you would prefer to use an easy framework: drivers/gpio/gpio-omap.c

Sunil,

Per the message you are getting:

[ 1072.206115] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:135 l3_interrupt_h)
[ 1072.215667] CUSTOM SRESP error with SOURCE:L4 PER2        

See the post http://e2e.ti.com/support/omap/f/849/t/176367.aspx 

Please ensure that you are using a recent x-loader matched to your particular release.

Regards,

Gina

Hi ICe,

Thanks for the response.

Its giving exception when I am writing into that register. If I comment it , it works fine.

I already enabled the GPIO5 clock as,

clkenable=ioremap(0x4A009478,sizeof(unsigned int));   // CM_L4PER_GPIO5_CLKCTRL.MODULEMODE set to 1

*clkenable &=0xFFFFFFFD; 

I am not using this clearing of IRQ status in the ISR. It is in probe function , I am clearing  the IRQ  status just to make sure.

So only when I insert my module it is called.

I tried using the gpio-omap.c API's.

There is an API " _clear_gpio_irqstatus(struct gpio_bank *bank,int gpio)"

But I am not sure of the first argument struct gpio_bank *bank  to pass from my driver.

Regards,

Sunil

Hi ICe,

I have changed the register setting as you suggested, but without any success.

Still I am getting the same exception.

Actually I am not getting any interrupt on GPIO 155 if I load my release mode driver.

If I load Debug mode driver and remove it and then insert Release mode driver, the interrupt is working fine.

So I am just thinking if any status is cleared in debug mode.

Regards,

Sunil.

Hi Sunil,

What do you mean by driver in debug mode?, what are the differences on the driver?