Having trouble with a BeagleBoard GPIO interrupt pin
来源：互联网 发布：vfp 编程论坛 编辑：程序博客网 时间：2024/05/16 18:02
Re: [Xenomai-help] Having trouble with a BeagleBoard GPIO interrupt pin
Header
Content
Posted by Philippe Gerum on August 10, 2010 - 08:44:
On Mon, 2010-08-09 at 23:22 -0700, Bob Feretich wrote:
The below sequence worked around the problem:insmod linux_asuspidvr.ko <-- this driver set the xxxDETET registersvia request_irq()rmmod linux_asuspidvr.ko <-- the driver exits, but the xxxDETECTregisters remain setinsmod rt_asuspidvr.ko <-- interrupts now seem to occur properlySo I modified the rt driver probe routine to do the below: ret = request_irq(irq, adis_data_rdy_dummy_irq_handler, IRQF_TRIGGER_FALLING | IRQF_DISABLED, "asuspidvr", adis_data_rdy_dummy_irq_handler);... disable_irq(GPIO133);... ret = rtdm_irq_request(&adis_data_rdy_irq_handle, irq, adis_data_rdy_irq_handler, RTDM_IRQTYPE_EDGE, "asuspidvr", ctx); ret = rtdm_irq_enable(&adis_data_rdy_irq_handle);...This seems to be working! I can now run the rt driver without firstrunning the Linux driver. :-) Do you see any problem with me continuing with the above temp fix?
No, because you only use request_irq() to set up the GPIO line properly,but you don't actually share the interrupt between linux and Xenomai,which is ok.
Philippe,I don't understand your response (below). It is too deep inAdeos/Xenomai technical details.After the issues are worked out on -core, please report back to -helpto let us know what we are to do.
In short, Xenomai does not fully configure an interrupt line the wayrequest_irq() does, this is the problem. Having the per-IRQ chipset_type() handler called is required to set the xxxDETECT bits in yourcase, and our low-level code (i.e. rthal_irq_request indirectly calledfrom rtdm_irq_request) does not do that.
It would also help if you could better describe the meaning of thertdm_irq_request() flags and whether the Linux request_irq() flagshave any implications to Adeos.
They have none. The edge flag is purely Xenomai-related. When shared IRQsupport is enabled, the EDGE flags passed to rtdm_irq_request() justgives a hint to the Xenomai interrupt dispatcher for dealing with edgeinterrupt handlers properly.
For example, I was quite surprised that both the request_irq() andrtdm_irq_request() to the same IRQ succeeded even though neitherincluded a SHARE flag. This seems to require a rt driver to call bothroutines to protect its xxxDetect registers.
This is a current flaw in the Xenomai interrupt management routines;they should allow the IRQ trigger info to be defined when requesting anIRQ (via rtdm_irq_request) the same way request_irq() does on the linuxside, but they do not support this yet.request_irq and rtdm_irq_request are not supposed to work together; IRQsharing between linux and Xenomai is not formally defined, because it issemantically wrong. Actually, a real-time interrupt hooked viartdm_irq_request should not be grabbed via request_irq() at the sametime for handling the IRQ. This would mean that both linux and the rtdomain share that interrupt, which would introduce a flaw, since adependency would exist between the non-rt linux handling and the rthandling of the same IRQ. Think of a level-triggered IRQ, requiringlinux to handle it before it is unmasked anew. To prevent an interruptstorm, the rt domain would then have to wait for the non-rt one (i.e.linux) to unmask the interrupt channel (i.e. maybe a non-rt device isrequiring attention), thus introducing an unbounded latency.
Regards,Bob FeretichOn 8/9/2010 10:35 PM, Philippe Gerum wrote:On Mon, 2010-08-09 at 19:19 +0200, Gilles Chanteperdrix wrote:Philippe Gerum wrote:On Mon, 2010-08-09 at 13:50 +0200, Gilles Chanteperdrix wrote:Philippe Gerum wrote:On Mon, 2010-08-09 at 02:54 -0700, Bob Feretich wrote:I am converting my second driver to RTDM. This one receives anegativing going edge triggered interrupt on GPIO133 of the OMAP3chip.I have...ret = rtdm_irq_request(&adis_data_rdy_irq_handle, irq, adis_data_rdy_irq_handler, RTDM_IRQTYPE_EDGE, "asuspidvr", ctx);then...ret = rtdm_irq_enable(&adis_data_rdy_irq_handle);but the interrupt handler is never invoked.cat /proc/xenomai/irq shows:IRQ CPU0 37: 15815 [timer] 39: 0 asuspidvr 48: 0 asuspidvr 91: 0 asuspidvr293: 0 asuspidvr418: 0 [virtual]IRQ 293 in the interrupt that should be happening.I can see the pulses on the input pin and the non-rt version of thedriver sees the interrupts, so that excludes hardware issues andu-boot pin configuration issues.Any suggestions?Regards,Bob Feretich__For some reason, that IRQ line may not be properly enabled by the corecode. Could you introduce this patch? If a valid routine is reported inthe kernel log message, you could locate it by address, from a kernelimage objdump.There may also be more to do than enabling the irq line, such asprogramming the hardware to enable irq for this gpio, set the type(edge, level) and so on. You can try and call request_irq, then free_irqbefore calling rtdm_request_irq to see if request_irq would trigger someactions that rtdm_request_irq does not trigger.If you mean that beagle_twl_gpio_setup() still has to be called at thispoint, then we probably have something broken at ipipe level.I was rather thinking about gpio_irq_type, which is normally calledthrough "set_irq_type". I wonder however, if calling this function foran irq registered through rtdm will not screw things up, especiallysince it changes the flow handler, or do nothing because the irq has notbeen registered with request_irq.chip->set_type() should be called when setting the IRQ trigger; this onecompletely depends on the per-chip routine. In the gpio_irq_type(), thatshould be fine, since we relay the settings through__fixup_irq_handler(), which is Adeos-defined.Xenomai is not currently setting the IRQ trigger when requesting aninterrupt, which is the problem. However, set_type() handlers are oftenrequired to run in secondary mode; this means than any call on behalf ofrtdm_irq_request() would restrict the latter to secondary mode only,which is not currently the case.This means that we should probably force this requirement onrthal_irq_request() at some point, because connecting a Xenomaiinterrupt descriptor to the Linux core may impose secondary mode on us.PS: switching the discussion to -core where it belongs now.
-- Philippe.
Related Messages
Powered by MHonArc, Updated Tue Aug 10 09:20:14 2010
- Having trouble with a BeagleBoard GPIO interrupt pin
- UVa 10286 - Trouble with a Pentagon
- UVA, 10286 Trouble with a Pentagon
- uva 10286 Trouble with a Pentagon
- mt2523 [keypad]how to config keydata mapping with GPIO pin?
- Using OpenOCD with BeagleBoard-xM
- The Trouble With Multicore
- The Trouble With Girls
- "The Trouble with Checked Exceptions A Conversation with Anders Hejlsberg, Part II" 阅读笔记
- Learning ADSP-TS201系列--Interrupt Pin
- Trouble is a friend
- Trouble is a friend
- trouble is a friend
- BeagleBoard Rev C5 Simple System with Buildroot
- 在 BeagleBoard Black Angstrom操作系统下使用GPIO，PWM
- Raspberry Pi GPIO with Python (A WiringPi wrapper :D)
- The Trouble with Checked Exceptions
- Samsung ARTIK 530 GPIO PIN programming
- SVN常见问题与解决方法
- Hadoop 坑爹的Be Replicated to 0 nodes, instead of 1 异常
- Windows CE安装（转）
- iOS动态监听网络变化
- wince应用开发的一些小功能（备忘）
- Having trouble with a BeagleBoard GPIO interrupt pin
- 如何让listview滚动到底部
- oracle导入导出表exp以及创建用户和创建表空间
- RTSP 概述
- UINavigationController popToViewController直接返回指定级别页面
- IOS设计模式学习（23）备忘录
- 性能loadrunner--load generation按钮
- freeswitch sofia
- apk的安装和卸载
