On Sat, May 30, 2015 at 7:12 AM, Gilles Chanteperdrix <[email protected]> wrote: > On Fri, May 29, 2015 at 02:32:51PM -0700, Hongfei Cheng wrote: >> Two questions: >> 1). Is the linux spinlock used in its scheduler's complete() function safe >> in this chain of spinlocks? > > Definitely not. Obviously. I am even surprised you ask.
What surprised me is that, with a Linux spinlock in the loop, the platform driver is probed successfully and the system boots just fine with I-pipe and Xenomai enabled. We can even run the latency test with reasonable results. What are the obvious signs to look for when: 1). a Linux spinlock is mistakenly used in place of an ipipe spinlock? 2). an ipipe spinlock is mistakenly used in place of a Linux spinlock? >> 2). Is there any risk if gic_arch_extn.irq_hold() and >> gic_arch_extn.irq_release() are set as NULL (in the platform driver)? > > There should be no reason to define this archiecture hold and > release. Using the mask and unmask ones should be sufficient. When gic_arch_extn is defined by the platform driver, without making the changes in gic_hold_irq() and gic_release_irq(), we'd get the following incorrect call stack, which you previously confirmed. The platform driver also fails during system bootup. msm_mpm_disable_irq+0xc/0x18 gic_hold_irq+0xb8/0x134 __ipipe_ack_fasteoi_irq+0x14/0x20 __ipipe_dispatch_irq+0x90/0x2a8 __ipipe_grab_irq+0x5c/0x74 By the way, what are the purposes of gic_hold_irq() and gic_release_irq()? Thanks, Hongfei _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
