From: Heilpern, M. <mar...@au...> - 2006-08-23 19:39:09
|
I'm trying to tie a GPIO to an interrupt and though I can see the line getting set (using a logic analyzer and also /proc/gpio/GPIO29), the interrupt doesn't happen. Any ideas? =20 Here is the relevant code pieces for my module: =20 #define GPIO_INTERRUPT 29 ... pxa_gpio_mode(GPIO_INTERRUPT | GPIO_IN); ... if (request_irq(IRQ_GPIO(GPIO_INTERRUPT), autc_irq, SA_SHIRQ, "AES", (void *)FPS_TYPE)) { /* if we reach this point, the ISR could not be installed */ err("ISR cannot be installed :("); autc_ps_release_hw(); return -1; } ... set_irq_type(IRQ_GPIO(GPIO_INTERRUPT), IRQT_RISING); ... // do something that will cause GPIO29 to rise ... ... ... =20 =20 =20 =20 I can see the GPIO is set as an input, and currently set, using proc_gpio. My trivial ISR performs a printk() so I'll know if it's been hit, but it never shows up in my system log. "cat /proc/interrupts" also shows 0 as the run count for this interrupt: 52: 0 AES =20 =20 I haven't done anything to explicitly disable the interrupt vector (and I haven't done anything to explicitly enable it either). =20 _______________________________________________________ NOTE: The information in this message is intended for the personal and = confidential use of the designated recipient(s) named above. To the extent the = recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an = obligation of confidentiality, with AuthenTec, then this message and/or any = attachments shall be considered confidential information and subject to the confidentiality = terms of that agreement. If the reader of this message is not the intended recipient = named above, you are notified that you have received this document in error, and any = review, dissemination, distribution or copying of this message is strictly prohibited. If you = have received this document in error, please delete the original message and notify the = sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com |
From: Dave H. <dhy...@gm...> - 2006-08-31 05:33:49
|
Hi Mark, I found that I had started to answer this but forgot to hit send, so it was sitting in my Drafts. Sorry about that. > I'm trying to tie a GPIO to an interrupt and though I can see the line > getting set (using a logic analyzer and also /proc/gpio/GPIO29), the > interrupt doesn't happen. Any ideas? > > Here is the relevant code pieces for my module: > > #define GPIO_INTERRUPT 29 > ... > pxa_gpio_mode(GPIO_INTERRUPT | GPIO_IN); > ... > if (request_irq(IRQ_GPIO(GPIO_INTERRUPT), autc_irq, > SA_SHIRQ, > "AES", (void *)FPS_TYPE)) { I notice that you're using SA_SHIRQ, which means that you're requesting a shared IRQ. Is there a particular reason that you're using shared interrupts? The first time request_irq is called for a shared IRQ, that interrupt will be enabled. The second & subsequenct handlers which are sharing the IRQ do not cause the interrupt to be re-enabled. I see that GPIO 29 corresponds the to the audio SDATA line. Are you using the audio driver? I don't see anythng obvious that should cause things to not work. enabling & disabling of interrupts requires balanced calls to disable/enable. Can you send more code? -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Heilpern, M. <mar...@au...> - 2006-08-31 11:28:40
|
Hi Dave, =20 That particular problem turned out to be a bad connection to the = breakout board rather than software. =20 I'm not using the audio driver, just stealing some unused GPIOs. I was = under the impression that since my ISR is attached to a GPIO (in the = range of 2-84) that I was required to make it a shared interrupt. Is = this not the case? =20 Thanks, Mark =20 ________________________________ From: gum...@li... on behalf of Dave = Hylands Sent: Thu 8/31/2006 1:33 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Interrupt service routine not getting = called Hi Mark, I found that I had started to answer this but forgot to hit send, so it was sitting in my Drafts. Sorry about that. > I'm trying to tie a GPIO to an interrupt and though I can see the line > getting set (using a logic analyzer and also /proc/gpio/GPIO29), the > interrupt doesn't happen. Any ideas? > > Here is the relevant code pieces for my module: > > #define GPIO_INTERRUPT 29 > ... > pxa_gpio_mode(GPIO_INTERRUPT | GPIO_IN); > ... > if (request_irq(IRQ_GPIO(GPIO_INTERRUPT), autc_irq, > SA_SHIRQ, > "AES", (void *)FPS_TYPE)) { I notice that you're using SA_SHIRQ, which means that you're requesting a shared IRQ. Is there a particular reason that you're using shared interrupts? The first time request_irq is called for a shared IRQ, that interrupt will be enabled. The second & subsequenct handlers which are sharing the IRQ do not cause the interrupt to be re-enabled. I see that GPIO 29 corresponds the to the audio SDATA line. Are you using the audio driver? I don't see anythng obvious that should cause things to not work. enabling & disabling of interrupts requires balanced calls to = disable/enable. Can you send more code? -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users _______________________________________________________ NOTE: The information in this message is intended for the personal and = confidential use of the designated recipient(s) named above. To the extent the = recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an = obligation of confidentiality, with AuthenTec, then this message and/or any = attachments shall be considered confidential information and subject to the confidentiality = terms of that agreement. If the reader of this message is not the intended recipient = named above, you are notified that you have received this document in error, and any = review, dissemination, distribution or copying of this message is strictly prohibited. If you = have received this document in error, please delete the original message and notify the = sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com |
From: Dave H. <dhy...@gm...> - 2006-08-31 14:39:02
|
Hi Mark, > That particular problem turned out to be a bad connection to the breakout board rather than software. > > I'm not using the audio driver, just stealing some unused GPIOs. I was under the impression that since my ISR is attached to a GPIO (in the range of 2-84) that I was required to make it a shared interrupt. Is this not the case? No. A shared interrupt is one which can have multiple handlers assigned to it, presumably because there are multiple devices connected to the line which can drive it. The normal situation is that the interrupt would be active-low and each device would have an open-collector driver and there would be a pull-up resistor on the line. When the interrupt fires, the dispatcher hands it to the first handler, and if it doesn't handle it, then it calls the second handler, etc. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |