[Xenomai] I-pipe error when requesting irq that is on omap gpio

[Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:

[58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
[58531.105521]         into a regular Linux service
[58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
[58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
[58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
[58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
[58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
[58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
[58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
[58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
[58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
[58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
[58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
[58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
[58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
[58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
[58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
[58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
[58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
[58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
[58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
[58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
[58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
[58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
[58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
[58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
[58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
[58531.106652] ---[ end trace dff1d3990fff1b03 ]---
[58531.106718] ------------[ cut here ]------------
[58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
)
[58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
ol dwc3_omap lm75 [last unloaded: xfrm_user]
[58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
[58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
[58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
[58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
[58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
[58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
[58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])

I saw ipipe patches in the gpio-omap.c but maybe something is still
missing.

Any ideas?

Of course it may be that our code is used to running on an older xenomai
where it first called request_irq and then xenomai took over the irq
handling.  I wish the person that wrote that code still worked here to
explain why that was done.

If I don't use the gpio irq but instead use an irq that is one level
lower, then I get no such error message (although the pin isn't setup
properly either then so it doesn't actually work either).

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 04:24 PM, Lennart Sorensen wrote:
> I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
> 
> [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
> [58531.105521]         into a regular Linux service
> [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
> [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
> [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
> [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
> [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
> [58531.106718] ------------[ cut here ]------------
> [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
> )
> [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
> pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
> nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
> ol dwc3_omap lm75 [last unloaded: xfrm_user]
> [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> 
> I saw ipipe patches in the gpio-omap.c but maybe something is still
> missing.
> 
> Any ideas?
> 
> Of course it may be that our code is used to running on an older xenomai
> where it first called request_irq and then xenomai took over the irq
> handling.  I wish the person that wrote that code still worked here to
> explain why that was done.
> 
> If I don't use the gpio irq but instead use an irq that is one level
> lower, then I get no such error message (although the pin isn't setup
> properly either then so it doesn't actually work either).
> 
This is a simple warning which should be harmless, it should not prevent
the irq from working. Now we had an old issue on ARM, which is that an
irq line should be enabled before using it, the simplest way to get it
enabled being to call request_irq before rtdm_irq_request. Maybe this
issue we believed fixed is still there?

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 04:57:34PM +0200, Gilles Chanteperdrix wrote:
> On 10/01/2014 04:24 PM, Lennart Sorensen wrote:
> > I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
> > 
> > [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
> > [58531.105521]         into a regular Linux service
> > [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> > [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> > [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> > [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
> > [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
> > [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
> > [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
> > [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> > [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> > [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> > [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> > [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> > [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> > [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> > [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> > [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> > [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> > [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> > [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> > [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> > [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> > [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> > [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> > [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> > [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> > [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
> > [58531.106718] ------------[ cut here ]------------
> > [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
> > )
> > [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
> > pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
> > nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
> > ol dwc3_omap lm75 [last unloaded: xfrm_user]
> > [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> > [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> > [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> > [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> > [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> > [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> > [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> > 
> > I saw ipipe patches in the gpio-omap.c but maybe something is still
> > missing.
> > 
> > Any ideas?
> > 
> > Of course it may be that our code is used to running on an older xenomai
> > where it first called request_irq and then xenomai took over the irq
> > handling.  I wish the person that wrote that code still worked here to
> > explain why that was done.
> > 
> > If I don't use the gpio irq but instead use an irq that is one level
> > lower, then I get no such error message (although the pin isn't setup
> > properly either then so it doesn't actually work either).
> > 
> This is a simple warning which should be harmless, it should not prevent
> the irq from working. Now we had an old issue on ARM, which is that an
> irq line should be enabled before using it, the simplest way to get it
> enabled being to call request_irq before rtdm_irq_request. Maybe this
> issue we believed fixed is still there?

Or maybe I still haven't got the gpio bank configured correctly to
actually be an interrupt pin.  It looked like the omap-gpio driver did
that all correctly, but with all the registers on these chips, who knows.

We are currently doing request_irq first, and it still doesn't see any
interrupts on the line.

So is this message a case of the gpio driver doing some setup that ipipe
thinks should only be done from linux while doing the irq reqeust from
xenomai's domain?

I wish the message had told me which linux thing I called that it didn't
think I should have.  That would have been helpful.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 05:02 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 04:57:34PM +0200, Gilles Chanteperdrix wrote:
>> On 10/01/2014 04:24 PM, Lennart Sorensen wrote:
>>> I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
>>>
>>> [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
>>> [58531.105521]         into a regular Linux service
>>> [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
>>> [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>>> [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>>> [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
>>> [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
>>> [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
>>> [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
>>> [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>>> [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>>> [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
>>> [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
>>> [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
>>> [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
>>> [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
>>> [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
>>> [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
>>> [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
>>> [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
>>> [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
>>> [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
>>> [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
>>> [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
>>> [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
>>> [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
>>> [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
>>> [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
>>> [58531.106718] ------------[ cut here ]------------
>>> [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
>>> )
>>> [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
>>> pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
>>> nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
>>> ol dwc3_omap lm75 [last unloaded: xfrm_user]
>>> [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
>>> [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>>> [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>>> [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
>>> [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
>>> [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
>>> [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
>>>
>>> I saw ipipe patches in the gpio-omap.c but maybe something is still
>>> missing.
>>>
>>> Any ideas?
>>>
>>> Of course it may be that our code is used to running on an older xenomai
>>> where it first called request_irq and then xenomai took over the irq
>>> handling.  I wish the person that wrote that code still worked here to
>>> explain why that was done.
>>>
>>> If I don't use the gpio irq but instead use an irq that is one level
>>> lower, then I get no such error message (although the pin isn't setup
>>> properly either then so it doesn't actually work either).
>>>
>> This is a simple warning which should be harmless, it should not prevent
>> the irq from working. Now we had an old issue on ARM, which is that an
>> irq line should be enabled before using it, the simplest way to get it
>> enabled being to call request_irq before rtdm_irq_request. Maybe this
>> issue we believed fixed is still there?
> 
> Or maybe I still haven't got the gpio bank configured correctly to
> actually be an interrupt pin.  It looked like the omap-gpio driver did
> that all correctly, but with all the registers on these chips, who knows.
> 
> We are currently doing request_irq first, and it still doesn't see any
> interrupts on the line.

Do you use gpio_to_irq to obtain the irq number?

> 
> So is this message a case of the gpio driver doing some setup that ipipe
> thinks should only be done from linux while doing the irq reqeust from
> xenomai's domain?
> 
> I wish the message had told me which linux thing I called that it didn't
> think I should have.  That would have been helpful.

Actually, it tells you that you called rt_intr_create from user-space,
which ends-up calling ipipe_set_irq_affinity, which is not happy because
it is not called from Linux domain. We modified ipipe_virtualize_irq to
avoid that (only checking for root domain when CONFIG_IPIPE_LEGACY is
not set), but we probably forgot the SMP case with ipipe_set_irq_affinity.

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 05:28:35PM +0200, Gilles Chanteperdrix wrote:
> Do you use gpio_to_irq to obtain the irq number?

Yes.  I tried doing request_irq from a dummy linux driver and I managed
to get an interrupt.  I can't seem to get xenomai to see the interrupt
though.  Hmm.

I see this:

root@len-rx1400:~# cat /proc/xenomai/irq 
IRQ         CPU0        CPU1
 30:     2294394     1660178         [timer]
398:           0           0         0000002d
1031:           0           0         [sync]
1032:           1           0         [timer-ipi]
1033:         531           1         [reschedule]
1034:           0           0         [virtual]
1038:      535719         531         [virtual]

398 is the IRQ for GPIO bank 7 pin 14.  The linux driver test got an
interrupt from the device on that pin, but when I use xenomai I am so
far not getting the interrupt as far as I can tell.

Maybe I should try and no longer call request_irq first.

> Actually, it tells you that you called rt_intr_create from user-space,
> which ends-up calling ipipe_set_irq_affinity, which is not happy because
> it is not called from Linux domain. We modified ipipe_virtualize_irq to
> avoid that (only checking for root domain when CONFIG_IPIPE_LEGACY is
> not set), but we probably forgot the SMP case with ipipe_set_irq_affinity.

Oh.  Well if you have a patch I can test that.  Or a suggestion for
where to go and try to fix it.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 11:46:41AM -0400, Lennart Sorensen wrote:
> Yes.  I tried doing request_irq from a dummy linux driver and I managed
> to get an interrupt.  I can't seem to get xenomai to see the interrupt
> though.  Hmm.
> 
> I see this:
> 
> root@len-rx1400:~# cat /proc/xenomai/irq 
> IRQ         CPU0        CPU1
>  30:     2294394     1660178         [timer]
> 398:           0           0         0000002d
> 1031:           0           0         [sync]
> 1032:           1           0         [timer-ipi]
> 1033:         531           1         [reschedule]
> 1034:           0           0         [virtual]
> 1038:      535719         531         [virtual]
> 
> 398 is the IRQ for GPIO bank 7 pin 14.  The linux driver test got an
> interrupt from the device on that pin, but when I use xenomai I am so
> far not getting the interrupt as far as I can tell.
> 
> Maybe I should try and no longer call request_irq first.

That didn't seem to make any difference except of course now the IRQ
doesn't get listed in /proc/interrupts anymore.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 11:52:52AM -0400, Lennart Sorensen wrote:
> That didn't seem to make any difference except of course now the IRQ
> doesn't get listed in /proc/interrupts anymore.

Question:

When I do request_irq I can specify IRQF_TRIGGER_HIGH.  How does one do
the same thing for rt_intr_create?  After all that is an important thing
to tell the irq controller in this case.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 06:02 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 11:52:52AM -0400, Lennart Sorensen wrote:
>> That didn't seem to make any difference except of course now the IRQ
>> doesn't get listed in /proc/interrupts anymore.
> 
> Question:
> 
> When I do request_irq I can specify IRQF_TRIGGER_HIGH.  How does one do
> the same thing for rt_intr_create?  After all that is an important thing
> to tell the irq controller in this case.
> 
I guess you have to manually call irq_set_irq_type, that being said, if
you used request_irq, the GPIO should be configured and the type set. If
you register the Xenomai interrupt after that, it should get the
interrupt, if it does not get it, it probably means that you have an
issue in the gpio demuxing code.

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 07:31:53PM +0200, Gilles Chanteperdrix wrote:
> I guess you have to manually call irq_set_irq_type, that being said, if
> you used request_irq, the GPIO should be configured and the type set. If
> you register the Xenomai interrupt after that, it should get the
> interrupt, if it does not get it, it probably means that you have an
> issue in the gpio demuxing code.

So I found now that if I do request_irq first and then rt_intr_create,
then if I pass TRIGGER_HIGH or TRIGGER_LOW, then the system hangs as
soon as rt_intr_create is called (right after dumping the nice message
from ipipe I had in the first email).  If I do request_irq without that,
then it does not hang.  How odd.

If I don't use rt_intr_create and just have a dummy handler in linux
with request_irq, then I get a triggered interrrupt.

Of course if request_irq doesn't specify, then the default is
IRQF_TRIGGER_NONE, which in the gpio-omap driver means not calling
either of handle_level_irq or handle_edge_irq, so it probably isn't doing
anything in that case.  Passing in a trigger makes it call one of those
two functions depending on the trigger type requested.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 07:40 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 07:31:53PM +0200, Gilles Chanteperdrix wrote:
>> I guess you have to manually call irq_set_irq_type, that being said, if
>> you used request_irq, the GPIO should be configured and the type set. If
>> you register the Xenomai interrupt after that, it should get the
>> interrupt, if it does not get it, it probably means that you have an
>> issue in the gpio demuxing code.
> 
> So I found now that if I do request_irq first and then rt_intr_create,
> then if I pass TRIGGER_HIGH or TRIGGER_LOW, then the system hangs as
> soon as rt_intr_create is called (right after dumping the nice message
> from ipipe I had in the first email).  If I do request_irq without that,
> then it does not hang.  How odd.

Are you sure you are not simply getting an interrupt and failing to
clear the interrupt condition?

Are you sure that the GPIO demuxing code calls ipipe_handle_demuxed_irq
instead of generic_handle_irq?

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 07:46:31PM +0200, Gilles Chanteperdrix wrote:
> Are you sure you are not simply getting an interrupt and failing to
> clear the interrupt condition?

I won't claim to be sure yet.

> Are you sure that the GPIO demuxing code calls ipipe_handle_demuxed_irq
> instead of generic_handle_irq?

Well gpio-omap has this:

        if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
                __irq_set_handler_locked(d->irq, handle_level_irq);
        else if (type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
                __irq_set_handler_locked(d->irq, handle_edge_irq);


So I imagine it would call handle_level_irq in my case.  When I don't
specify HIGH or LOW, it would call neither and I get no hang.  I did
not try FALLING or RISING yet, although currently I suspect those would
hang too.

I also see:

                        ipipe_handle_demuxed_irq
                                (irq_find_mapping(bank->domain, bit));

That's in gpio-omap as well.  I see no calls to generic_handle_irq?

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 01:54:37PM -0400, Lennart Sorensen wrote:
> Well gpio-omap has this:
> 
>         if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
>                 __irq_set_handler_locked(d->irq, handle_level_irq);
>         else if (type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
>                 __irq_set_handler_locked(d->irq, handle_edge_irq);
> 
> 
> So I imagine it would call handle_level_irq in my case.  When I don't
> specify HIGH or LOW, it would call neither and I get no hang.  I did
> not try FALLING or RISING yet, although currently I suspect those would
> hang too.
> 
> I also see:
> 
>                         ipipe_handle_demuxed_irq
>                                 (irq_find_mapping(bank->domain, bit));
> 
> That's in gpio-omap as well.  I see no calls to generic_handle_irq?

I noticed gpio_unmask_irq in gpio-omap.c uses irqd_get_trigger_type to
get the existing trigger type in case if was masked by setting it to
type NONE.  I don't see anywhere actually calling irqd_set_trigger_type
though to actually populate the data with the desired trigger.  Maybe I
just missed it but I just don't see where that is being done.  Doesn't
explain the hang, but sure looks weird.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 07:54 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 07:46:31PM +0200, Gilles Chanteperdrix wrote:
>> Are you sure you are not simply getting an interrupt and failing to
>> clear the interrupt condition?
> 
> I won't claim to be sure yet.

Well, what is on the other end of the GPIO ? If this is a button, you
may want to set the interrupt type to edge, otherwise the interrupt will
remain asserted as long as you press the button, and you will get an
interrupt storm. If it is another GPIO, then you should reset that GPIO
state in the irq handler.

Also, it may actually be simpler to write an RTDM driver than to use the
deprecated, error-prone rtintr API.

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 11:39:26PM +0200, Gilles Chanteperdrix wrote:
> Well, what is on the other end of the GPIO ? If this is a button, you
> may want to set the interrupt type to edge, otherwise the interrupt will
> remain asserted as long as you press the button, and you will get an
> interrupt storm. If it is another GPIO, then you should reset that GPIO
> state in the irq handler.

No it is a marvell switch chip.  And it is in fact level triggered.
And it does clear when handled.

And I could probably get a button hooked up for testing, and just use
the debouncing feature in the gpio system to make it more manageable.

I am still not convinced the gpio-omap doesn't have a problem, but maybe
it is OK.

> Also, it may actually be simpler to write an RTDM driver than to use the
> deprecated, error-prone rtintr API.

Fair enough.  May have to consider that.  At the moment the system is
polling the switch chip given the IRQ isn't working yet, so idially we
want it working, but it isn't preventing things from working completely.

I will have a look at the rtdm stuff.

-- 
Len Sorensen

[Xenomai] Xenomai on Cortex R (or Rreal Time) family

[mobin Motallebizadeh]

Hi
can I build xenomai for armv7-r architecture? 
I can't see this mentioned anywhere (surprisingly!)
Is it same as other MMU-less archs(nios II ,e.g.)?
thanks in advance
 		 	   		  

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Gilles Chanteperdrix]

On 10/02/2014 03:56 PM, mobin Motallebizadeh wrote:
> Hi
> can I build xenomai for armv7-r architecture? 
> I can't see this mentioned anywhere (surprisingly!)
> Is it same as other MMU-less archs(nios II ,e.g.)?
> thanks in advance

This is a very legitimate question, but why are you hi-jacking a
discussion thread to ask it? Please do not reply a mail from another
discussion to ask a new question, this breaks archives for people who
want to browse the archives by discussion thread.

-- 
                                                                Gilles.

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[mobin Motallebizadeh]

 
> Date: Thu, 2 Oct 2014 16:00:57 +0200
> From: gilles.chanteperdrix@xenomai.org
> To: mobin.seven@live.com; xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family
> 
> On 10/02/2014 03:56 PM, mobin Motallebizadeh wrote:
> > Hi
> > can I build xenomai for armv7-r architecture? 
> > I can't see this mentioned anywhere (surprisingly!)
> > Is it same as other MMU-less archs(nios II ,e.g.)?
> > thanks in advance
> 
> This is a very legitimate question, but why are you hi-jacking a
> discussion thread to ask it? Please do not reply a mail from another
> discussion to ask a new question, this breaks archives for people who
> want to browse the archives by discussion thread.
> 
> -- 
>                                                                 Gilles.
 OMG! where should I ask it? I sent this to xenomai_at_org mail.sorry I always did this way!! 		 	   		  

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Lennart Sorensen]

On Thu, Oct 02, 2014 at 02:22:35PM +0000, mobin Motallebizadeh wrote:
>  OMG! where should I ask it? I sent this to xenomai_at_org mail.sorry I always did this way!!

Well you did it by replying to a thread rather than sending a new message
to xenomai@xenomai.org (changing the subject is NOT the same thing as
creating a new thread).  When you hit reply your email client inserts
a tag in the mssage saying which other message it was a reply to.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 01:40:29PM -0400, Lennart Sorensen wrote:
> So I found now that if I do request_irq first and then rt_intr_create,
> then if I pass TRIGGER_HIGH or TRIGGER_LOW, then the system hangs as
> soon as rt_intr_create is called (right after dumping the nice message
> from ipipe I had in the first email).  If I do request_irq without that,
> then it does not hang.  How odd.

Also interesting.  If I pass TRIGGER_RISING instead of HIGH or LOW,
then it does not hang (but also does not see any interrupts).

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 10:24:16AM -0400, Lennart Sorensen wrote:
> I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
> 
> [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
> [58531.105521]         into a regular Linux service
> [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
> [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
> [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
> [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
> [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
> [58531.106718] ------------[ cut here ]------------
> [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
> )
> [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
> pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
> nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
> ol dwc3_omap lm75 [last unloaded: xfrm_user]
> [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> 
> I saw ipipe patches in the gpio-omap.c but maybe something is still
> missing.
> 
> Any ideas?
> 
> Of course it may be that our code is used to running on an older xenomai
> where it first called request_irq and then xenomai took over the irq
> handling.  I wish the person that wrote that code still worked here to
> explain why that was done.
> 
> If I don't use the gpio irq but instead use an irq that is one level
> lower, then I get no such error message (although the pin isn't setup
> properly either then so it doesn't actually work either).

I discovered that if I comment out:

#ifdef CONFIG_SMP
        xnarch_set_irq_affinity(intr->irq, nkaffinity);
#endif /* CONFIG_SMP */

I stop getting the huge backtrace and warning about calling a linux
service from xenomai.

The omap-gpio driver does NOT support setting irq_affinity (and from
what I see, neither does any other gpio based irq driver).

It still locks up though, so the warning is clearly just a warning,
and not the cause of the lockup.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Philippe Gerum]

On 11/07/2014 07:26 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 10:24:16AM -0400, Lennart Sorensen wrote:
>> I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
>>
>> [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
>> [58531.105521]         into a regular Linux service
>> [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
>> [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>> [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>> [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
>> [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
>> [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
>> [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
>> [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>> [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>> [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
>> [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
>> [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
>> [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
>> [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
>> [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
>> [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
>> [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
>> [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
>> [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
>> [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
>> [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
>> [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
>> [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
>> [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
>> [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
>> [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
>> [58531.106718] ------------[ cut here ]------------
>> [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
>> )
>> [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
>> pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
>> nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
>> ol dwc3_omap lm75 [last unloaded: xfrm_user]
>> [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
>> [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>> [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>> [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
>> [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
>> [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
>> [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
>>
>> I saw ipipe patches in the gpio-omap.c but maybe something is still
>> missing.
>>
>> Any ideas?
>>
>> Of course it may be that our code is used to running on an older xenomai
>> where it first called request_irq and then xenomai took over the irq
>> handling.  I wish the person that wrote that code still worked here to
>> explain why that was done.
>>
>> If I don't use the gpio irq but instead use an irq that is one level
>> lower, then I get no such error message (although the pin isn't setup
>> properly either then so it doesn't actually work either).
> 
> I discovered that if I comment out:
> 
> #ifdef CONFIG_SMP
>         xnarch_set_irq_affinity(intr->irq, nkaffinity);
> #endif /* CONFIG_SMP */
> 
> I stop getting the huge backtrace and warning about calling a linux
> service from xenomai.

For this particular issue, Xenomai 2.x is deadly wrong. Creating,
deleting, enabling or disabling an IRQ channel must be done from
secondary mode. The syscall mode bits for these native API calls are
wrong, should be as follows instead:

diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
index 950b092..dff7f4d 100644
--- a/ksrc/skins/native/syscall.c
+++ b/ksrc/skins/native/syscall.c
@@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
 	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
 	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
 	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
-	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
+	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
 	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
-	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
+	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
 	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
-	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
-	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
+	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
+	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
 	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
 	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
 	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},

-- 
Philippe.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
> On 11/07/2014 07:26 PM, Lennart Sorensen wrote:
> > On Wed, Oct 01, 2014 at 10:24:16AM -0400, Lennart Sorensen wrote:
> >> I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
> >>
> >> [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
> >> [58531.105521]         into a regular Linux service
> >> [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> >> [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> >> [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> >> [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
> >> [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
> >> [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
> >> [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
> >> [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> >> [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> >> [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> >> [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> >> [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> >> [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> >> [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> >> [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> >> [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> >> [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> >> [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> >> [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> >> [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> >> [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> >> [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> >> [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> >> [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> >> [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> >> [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
> >> [58531.106718] ------------[ cut here ]------------
> >> [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
> >> )
> >> [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
> >> pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
> >> nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
> >> ol dwc3_omap lm75 [last unloaded: xfrm_user]
> >> [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> >> [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> >> [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> >> [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> >> [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> >> [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> >> [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> >>
> >> I saw ipipe patches in the gpio-omap.c but maybe something is still
> >> missing.
> >>
> >> Any ideas?
> >>
> >> Of course it may be that our code is used to running on an older xenomai
> >> where it first called request_irq and then xenomai took over the irq
> >> handling.  I wish the person that wrote that code still worked here to
> >> explain why that was done.
> >>
> >> If I don't use the gpio irq but instead use an irq that is one level
> >> lower, then I get no such error message (although the pin isn't setup
> >> properly either then so it doesn't actually work either).
> > 
> > I discovered that if I comment out:
> > 
> > #ifdef CONFIG_SMP
> >         xnarch_set_irq_affinity(intr->irq, nkaffinity);
> > #endif /* CONFIG_SMP */
> > 
> > I stop getting the huge backtrace and warning about calling a linux
> > service from xenomai.
> 
> For this particular issue, Xenomai 2.x is deadly wrong. Creating,
> deleting, enabling or disabling an IRQ channel must be done from
> secondary mode. The syscall mode bits for these native API calls are
> wrong, should be as follows instead:
> 
> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
> index 950b092..dff7f4d 100644
> --- a/ksrc/skins/native/syscall.c
> +++ b/ksrc/skins/native/syscall.c
> @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
>  	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
>  	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
>  	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
> -	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
> +	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
>  	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
> -	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
> +	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
>  	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
> -	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
> -	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
> +	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
> +	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
>  	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
>  	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
>  	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},

Oh nifty.  Will give that a try then.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
> For this particular issue, Xenomai 2.x is deadly wrong. Creating,
> deleting, enabling or disabling an IRQ channel must be done from
> secondary mode. The syscall mode bits for these native API calls are
> wrong, should be as follows instead:
> 
> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
> index 950b092..dff7f4d 100644
> --- a/ksrc/skins/native/syscall.c
> +++ b/ksrc/skins/native/syscall.c
> @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
>  	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
>  	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
>  	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
> -	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
> +	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
>  	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
> -	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
> +	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
>  	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
> -	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
> -	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
> +	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
> +	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
>  	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
>  	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
>  	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},

I get the impression this might also be important:

Index: linux-3.12.31.rr1/arch/arm/mach-omap2/timer.c
===================================================================
--- linux-3.12.31.rr1.orig/arch/arm/mach-omap2/timer.c  2014-11-07 10:10:47.736200170 -0500
+++ linux-3.12.31.rr1/arch/arm/mach-omap2/timer.c       2014-11-07 11:42:03.807512821 -0500
@@ -824,7 +824,8 @@
                omap2_sync32k_clocksource_init();                       \
        if (cpu_is_omap34xx())                                          \
                omap3_pic_muter_register();                             \
-       else if (cpu_is_omap44xx() || soc_is_omap54xx())                \
+       else if (cpu_is_omap44xx() || soc_is_omap54xx()                 \
+                || soc_is_dra7xx())                                    \
                omap4_pic_muter_register();                             \
 }
 #endif

The dra7xx (am57xx) we are using is very much like the omap54xx, and
use the same gpio system, so this call probably should be getting done.

Does that seem plausible?

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Fri, Nov 07, 2014 at 03:24:05PM -0500, Lennart Sorensen wrote:
> On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
> > For this particular issue, Xenomai 2.x is deadly wrong. Creating,
> > deleting, enabling or disabling an IRQ channel must be done from
> > secondary mode. The syscall mode bits for these native API calls are
> > wrong, should be as follows instead:
> > 
> > diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
> > index 950b092..dff7f4d 100644
> > --- a/ksrc/skins/native/syscall.c
> > +++ b/ksrc/skins/native/syscall.c
> > @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
> >  	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
> >  	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
> >  	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
> > -	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
> > +	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
> >  	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
> > -	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
> > +	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
> >  	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
> > -	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
> > -	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
> > +	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
> > +	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
> >  	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
> >  	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
> >  	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},
> 
> I get the impression this might also be important:
> 
> Index: linux-3.12.31.rr1/arch/arm/mach-omap2/timer.c
> ===================================================================
> --- linux-3.12.31.rr1.orig/arch/arm/mach-omap2/timer.c  2014-11-07 10:10:47.736200170 -0500
> +++ linux-3.12.31.rr1/arch/arm/mach-omap2/timer.c       2014-11-07 11:42:03.807512821 -0500
> @@ -824,7 +824,8 @@
>                 omap2_sync32k_clocksource_init();                       \
>         if (cpu_is_omap34xx())                                          \
>                 omap3_pic_muter_register();                             \
> -       else if (cpu_is_omap44xx() || soc_is_omap54xx())                \
> +       else if (cpu_is_omap44xx() || soc_is_omap54xx()                 \
> +                || soc_is_dra7xx())                                    \
>                 omap4_pic_muter_register();                             \
>  }
>  #endif
> 
> The dra7xx (am57xx) we are using is very much like the omap54xx, and
> use the same gpio system, so this call probably should be getting done.
> 
> Does that seem plausible?

This call enables "PIC muting". "PIC muting" means disabling non
real-time interrupts when in the Xenomai domain, i.e. when executing
real-time code. The I-pipe can work without that (as it does on many
platforms). So, if you suspect you have IRQ handling issues, you may
prefer to disable it, you do not want to suspect it of being the
cause of the issues you have.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Fri, Nov 07, 2014 at 09:32:35PM +0100, Gilles Chanteperdrix wrote:
> On Fri, Nov 07, 2014 at 03:24:05PM -0500, Lennart Sorensen wrote:
> > On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
> > > For this particular issue, Xenomai 2.x is deadly wrong. Creating,
> > > deleting, enabling or disabling an IRQ channel must be done from
> > > secondary mode. The syscall mode bits for these native API calls are
> > > wrong, should be as follows instead:
> > > 
> > > diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
> > > index 950b092..dff7f4d 100644
> > > --- a/ksrc/skins/native/syscall.c
> > > +++ b/ksrc/skins/native/syscall.c
> > > @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
> > >  	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
> > >  	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
> > >  	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
> > > -	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
> > > +	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
> > >  	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
> > > -	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
> > > +	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
> > >  	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
> > > -	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
> > > -	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
> > > +	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
> > > +	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
> > >  	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
> > >  	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
> > >  	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},
> > 
> > I get the impression this might also be important:
> > 
> > Index: linux-3.12.31.rr1/arch/arm/mach-omap2/timer.c
> > ===================================================================
> > --- linux-3.12.31.rr1.orig/arch/arm/mach-omap2/timer.c  2014-11-07 10:10:47.736200170 -0500
> > +++ linux-3.12.31.rr1/arch/arm/mach-omap2/timer.c       2014-11-07 11:42:03.807512821 -0500
> > @@ -824,7 +824,8 @@
> >                 omap2_sync32k_clocksource_init();                       \
> >         if (cpu_is_omap34xx())                                          \
> >                 omap3_pic_muter_register();                             \
> > -       else if (cpu_is_omap44xx() || soc_is_omap54xx())                \
> > +       else if (cpu_is_omap44xx() || soc_is_omap54xx()                 \
> > +                || soc_is_dra7xx())                                    \
> >                 omap4_pic_muter_register();                             \
> >  }
> >  #endif
> > 
> > The dra7xx (am57xx) we are using is very much like the omap54xx, and
> > use the same gpio system, so this call probably should be getting done.
> > 
> > Does that seem plausible?
> 
> This call enables "PIC muting". "PIC muting" means disabling non
> real-time interrupts when in the Xenomai domain, i.e. when executing
> real-time code. The I-pipe can work without that (as it does on many
> platforms). So, if you suspect you have IRQ handling issues, you may
> prefer to disable it, you do not want to suspect it of being the
> cause of the issues you have.

Well enabling it made no difference.  It wasn't there before.

The syscall.c change got rid of the complaint about calling linux services
from xenomai domain so that seems like an improvement.

I still get the warning about set_affinity not being supported (which
is true of course).

I still get the lockup, but I am not sure the realtime irq handler is
doing its job properly yet so still investigating that.  At least the
ugly warning is gone now.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
> For this particular issue, Xenomai 2.x is deadly wrong. Creating,
> deleting, enabling or disabling an IRQ channel must be done from
> secondary mode. The syscall mode bits for these native API calls are
> wrong, should be as follows instead:
> 
> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
> index 950b092..dff7f4d 100644
> --- a/ksrc/skins/native/syscall.c
> +++ b/ksrc/skins/native/syscall.c
> @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
>  	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
>  	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
>  	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
> -	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
> +	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
>  	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
> -	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
> +	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
>  	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
> -	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
> -	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
> +	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
> +	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
>  	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
>  	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
>  	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},

Are you sure all 4 of those had to change?  I can see intr_create and
intr_delete, but intr_enable and disable?  We are seeing insane latency
from realtime irqs on the omap gpio irqs (a few ms response to an irq).
Of course it could be the gpio irq is just doing something wrong.
Not sure yet.  Of course before doing this change we sometimes saw it
take close to 1s to call the realtime irq handler which made no sense
at all.  gic interrupts are working as expected and see no delays that
we are aware of at least.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Philippe Gerum]

On 11/17/2014 08:12 PM, Lennart Sorensen wrote:
> On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
>> For this particular issue, Xenomai 2.x is deadly wrong. Creating,
>> deleting, enabling or disabling an IRQ channel must be done from
>> secondary mode. The syscall mode bits for these native API calls are
>> wrong, should be as follows instead:
>>
>> diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
>> index 950b092..dff7f4d 100644
>> --- a/ksrc/skins/native/syscall.c
>> +++ b/ksrc/skins/native/syscall.c
>> @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
>>  	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
>>  	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
>>  	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
>> -	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
>> +	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
>>  	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
>> -	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
>> +	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
>>  	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
>> -	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
>> -	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
>> +	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
>> +	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
>>  	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
>>  	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
>>  	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},
> 
> Are you sure all 4 of those had to change?  I can see intr_create and
> intr_delete, but intr_enable and disable?  We are seeing insane latency
> from realtime irqs on the omap gpio irqs (a few ms response to an irq).

The reason to move all of these calls to lostage is that all of them may
have to traverse regular linux code, which cannot be made I-pipe aware
by design (e.g. PCI config code holding the big pci_lock). In such a
case, we certainly don't want them to be called from the middle of
nowhere linux-wise, e.g. from the real-time domain. So yes, all of them
must be switched to lostage mode.

> Of course it could be the gpio irq is just doing something wrong.
> Not sure yet.  Of course before doing this change we sometimes saw it
> take close to 1s to call the realtime irq handler which made no sense
> at all.  gic interrupts are working as expected and see no delays that
> we are aware of at least.
> 

This is likely a bug in the irq chip handling for these gpios lines.

-- 
Philippe.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Mon, Nov 17, 2014 at 08:44:10PM +0100, Philippe Gerum wrote:
> The reason to move all of these calls to lostage is that all of them may
> have to traverse regular linux code, which cannot be made I-pipe aware
> by design (e.g. PCI config code holding the big pci_lock). In such a
> case, we certainly don't want them to be called from the middle of
> nowhere linux-wise, e.g. from the real-time domain. So yes, all of them
> must be switched to lostage mode.

OK, fair enough.  I just wanted to confirm.

> This is likely a bug in the irq chip handling for these gpios lines.

Hmm, now for how to track that down.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Mon, Nov 17, 2014 at 02:12:37PM -0500, Lennart Sorensen wrote:
> On Fri, Nov 07, 2014 at 07:43:30PM +0100, Philippe Gerum wrote:
> > For this particular issue, Xenomai 2.x is deadly wrong. Creating,
> > deleting, enabling or disabling an IRQ channel must be done from
> > secondary mode. The syscall mode bits for these native API calls are
> > wrong, should be as follows instead:
> > 
> > diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
> > index 950b092..dff7f4d 100644
> > --- a/ksrc/skins/native/syscall.c
> > +++ b/ksrc/skins/native/syscall.c
> > @@ -4145,12 +4145,12 @@ static xnsysent_t __systab[] = {
> >  	[__native_alarm_stop] = {&__rt_alarm_stop, __xn_exec_any},
> >  	[__native_alarm_wait] = {&__rt_alarm_wait, __xn_exec_primary},
> >  	[__native_alarm_inquire] = {&__rt_alarm_inquire, __xn_exec_any},
> > -	[__native_intr_create] = {&__rt_intr_create, __xn_exec_any},
> > +	[__native_intr_create] = {&__rt_intr_create, __xn_exec_lostage},
> >  	[__native_intr_bind] = {&__rt_intr_bind, __xn_exec_conforming},
> > -	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_any},
> > +	[__native_intr_delete] = {&__rt_intr_delete, __xn_exec_lostage},
> >  	[__native_intr_wait] = {&__rt_intr_wait, __xn_exec_primary},
> > -	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_any},
> > -	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_any},
> > +	[__native_intr_enable] = {&__rt_intr_enable, __xn_exec_lostage},
> > +	[__native_intr_disable] = {&__rt_intr_disable, __xn_exec_lostage},
> >  	[__native_intr_inquire] = {&__rt_intr_inquire, __xn_exec_any},
> >  	[__native_pipe_create] = {&__rt_pipe_create, __xn_exec_lostage},
> >  	[__native_pipe_bind] = {&__rt_pipe_bind, __xn_exec_conforming},
> 
> Are you sure all 4 of those had to change?  I can see intr_create and
> intr_delete, but intr_enable and disable?  We are seeing insane latency
> from realtime irqs on the omap gpio irqs (a few ms response to an irq).
> Of course it could be the gpio irq is just doing something wrong.
> Not sure yet.  Of course before doing this change we sometimes saw it
> take close to 1s to call the realtime irq handler which made no sense
> at all.  gic interrupts are working as expected and see no delays that
> we are aware of at least.

Well, have you tried triggering an I-pipe tracer trace to see what
happens in the interval?

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Mon, Nov 17, 2014 at 09:14:35PM +0100, Gilles Chanteperdrix wrote:
> Well, have you tried triggering an I-pipe tracer trace to see what
> happens in the interval?

I have never used the tracer. I suppose I should learn how.

Any plans to merge that syscall.c fix into xenomai-2.6's tree for future
2.6.x releases?

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Mon, Nov 17, 2014 at 03:24:25PM -0500, Lennart Sorensen wrote:
> On Mon, Nov 17, 2014 at 09:14:35PM +0100, Gilles Chanteperdrix wrote:
> > Well, have you tried triggering an I-pipe tracer trace to see what
> > happens in the interval?
> 
> I have never used the tracer. I suppose I should learn how.

It is not very complicated. I have already been told on this list
that it was not well documented. I do not think so, but I let you
judge of that.

http://xenomai.org/2014/06/using-the-i-pipe-tracer/

> 
> Any plans to merge that syscall.c fix into xenomai-2.6's tree for future
> 2.6.x releases?

Yes, that is, assuming there will be a future Xenomai 2.6 release. 

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Mon, Nov 17, 2014 at 03:24:25PM -0500, Lennart Sorensen wrote:
> On Mon, Nov 17, 2014 at 09:14:35PM +0100, Gilles Chanteperdrix wrote:
> > Well, have you tried triggering an I-pipe tracer trace to see what
> > happens in the interval?
> 
> I have never used the tracer. I suppose I should learn how.
> 
> Any plans to merge that syscall.c fix into xenomai-2.6's tree for future
> 2.6.x releases?

Also note that I was kind of waiting for confirmation that it did
actually work, which so far has not happened.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Mon, Nov 17, 2014 at 09:30:17PM +0100, Gilles Chanteperdrix wrote:
> Also note that I was kind of waiting for confirmation that it did
> actually work, which so far has not happened.

Well your syscall.c changes got rid of the warning when registering the
irq, and it did make the interrupt response time we see a lot better
(although still not what we were hoping for).

So so far I intend to use your patch.  It seems to definitely be much
better.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Mon, Nov 17, 2014 at 09:27:54PM +0100, Gilles Chanteperdrix wrote:
> On Mon, Nov 17, 2014 at 03:24:25PM -0500, Lennart Sorensen wrote:
> > On Mon, Nov 17, 2014 at 09:14:35PM +0100, Gilles Chanteperdrix wrote:
> > > Well, have you tried triggering an I-pipe tracer trace to see what
> > > happens in the interval?
> > 
> > I have never used the tracer. I suppose I should learn how.
> 
> It is not very complicated. I have already been told on this list
> that it was not well documented. I do not think so, but I let you
> judge of that.
> 
> http://xenomai.org/2014/06/using-the-i-pipe-tracer/

So here is what I got triggering a couple of times on the IRQ.  Not
entirely sure how to make sense of it, although there is one huge number.

back_trace_points:100
enable:1
frozen:I-pipe frozen back-tracing service on 3.12-1-am5726/ipipe release #2
frozen:------------------------------------------------------------
frozen:CPU: 0, Freeze: 2415647132 cycles, Trace Points: 100 (+10)
frozen:Calibrated minimum trace-point overhead: 0.428 us
frozen: +----- Hard IRQs ('|': locked)
frozen: |+-- Xenomai
frozen: ||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
frozen: |||			  +---------- Delay flag ('+': > 1 us, '!': > 10 us)
frozen: |||			  |	   +- NMI noise ('N')
frozen: |||			  |	   |
frozen:	  Type	  User Val.   Time    Delay  Function (Parent)
frozen::    #func                -662	  0.857  arch_cpu_idle_enter+0x10 (cpu_startup_entry+0xb8)
frozen::    #func                -661	  1.000  ledtrig_cpu+0x10 (arch_cpu_idle_enter+0x1c)
frozen::    #func                -660	  1.000  led_trigger_event+0x10 (ledtrig_cpu+0x58)
frozen::    #func                -659+   1.285  _raw_read_lock+0x10 (led_trigger_event+0x30)
frozen::    #func                -658	  0.857  tick_check_broadcast_expired+0x10 (cpu_startup_entry+0x40)
frozen::    #func                -657	  1.000  rcu_idle_enter+0x10 (cpu_startup_entry+0x58)
frozen::    #func                -656	  0.857  ipipe_test_and_stall_root+0x10 (rcu_idle_enter+0x18)
frozen::    #func                -655	  0.857  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
frozen::|   #begin   0x80000001  -654+   1.428  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
frozen::|   #end     0x80000001  -653	  1.000  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
frozen::|   #begin   0x80000001  -652	  1.000  ipipe_test_and_stall_root+0x84 (rcu_idle_enter+0x18)
frozen::|   #end     0x80000001  -651	  1.000  ipipe_test_and_stall_root+0x70 (rcu_idle_enter+0x18)
frozen::    #func                -650	  1.000  rcu_eqs_enter_common.isra.47+0x14 (rcu_idle_enter+0x84)
frozen::    #func                -649	  1.000  arch_cpu_idle+0x10 (cpu_startup_entry+0x5c)
frozen::|   #begin   0x80000000  -648	  1.000  arch_cpu_idle+0xa4 (cpu_startup_entry+0x5c)
frozen::|   +func                -647! 555.142  omap_default_idle+0x10 (arch_cpu_idle+0x90)      <-- What ever is that?  That looks huge.
frozen::|   +end     0x80000000   -92+   1.142  omap_default_idle+0x40 (arch_cpu_idle+0x90)
frozen::|   +begin   0x90000000   -90	  1.000  __irq_svc+0x44 (omap_default_idle+0x44)
frozen::|   +func                 -89	  1.000  gic_handle_irq+0x10 (__irq_svc+0x58)
frozen::|   +func                 -88	  1.000  irq_find_mapping+0x14 (gic_handle_irq+0x30)
frozen::|   +func                 -87	  1.000  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
frozen::|   +begin   0x0000001b   -86	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
frozen::|   +func                 -85	  1.000  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
frozen::|   +func                 -84	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
frozen::|   +func                 -83	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
frozen::|   +func                 -82+   1.142  __ipipe_ack_hrtimer_irq+0x10 (__ipipe_dispatch_irq+0x70)
frozen::|   +func                 -81	  0.857  __ipipe_ack_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x60)
frozen::|   +func                 -80	  0.857  gic_hold_irq+0x10 (__ipipe_ack_fasteoi_irq+0x24)
frozen::|   +func                 -80+   2.428  __ipipe_spin_lock_irqsave+0x10 (gic_hold_irq+0x34)
frozen::|   #func                 -77+   1.285  __ipipe_spin_unlock_irqrestore+0x10 (gic_hold_irq+0x98)
frozen::|   +func                 -76	  1.000  arch_itimer_ack_virt+0x10 (__ipipe_ack_hrtimer_irq+0x70)
frozen::|   +func                 -75	  0.857  __ipipe_end_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x88)
frozen::|   +func                 -74	  1.000  gic_release_irq+0x10 (__ipipe_end_fasteoi_irq+0x2c)
frozen::|   +func                 -73+   1.142  __ipipe_spin_lock_irqsave+0x10 (gic_release_irq+0x34)
frozen::|   #func                 -72+   2.000  __ipipe_spin_unlock_irqrestore+0x10 (gic_release_irq+0x74)
frozen::|  # func                 -70+   1.285  xnintr_clock_handler+0x14 [xeno_nucleus] (__ipipe_dispatch_irq+0x270)
frozen::|  # func                 -69+   3.571  __xnlock_spin+0x14 [xeno_nucleus] (xnintr_clock_handler+0x420 [xeno_nucleus])
frozen::|  # func                 -65	  1.000  xntimer_tick_aperiodic+0x14 [xeno_nucleus] (xnintr_clock_handler+0x1e0 [xeno_nucleus])
frozen::|  # func                 -64	  0.857  xntimer_next_local_shot+0x10 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
frozen::|  # event   tick@-50     -63	  0.857  xntimer_next_local_shot+0xb4 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
frozen::|  # func                 -62	  1.000  ipipe_timer_set+0x10 (xntimer_next_local_shot+0xbc [xeno_nucleus])
frozen::|  # func                 -61+   1.428  arch_timer_set_next_event_virt+0x10 (ipipe_timer_set+0x7c)
frozen::|  # func                 -60	  1.000  xnintr_host_tick+0x10 [xeno_nucleus] (xnintr_clock_handler+0x368 [xeno_nucleus])
frozen::|  # func                 -59+   1.571  __ipipe_set_irq_pending+0x10 (xnintr_host_tick+0x54 [xeno_nucleus])
frozen::|   +func                 -57+   1.428  __ipipe_do_sync_pipeline+0x14 (__ipipe_dispatch_irq+0x33c)
frozen::|   +func                 -56+   1.142  __ipipe_do_sync_stage+0x14 (__ipipe_do_sync_pipeline+0x140)
frozen::|   #end     0x80000000   -55	  1.000  __ipipe_do_sync_stage+0x294 (__ipipe_do_sync_pipeline+0x140)
frozen::    #func                 -54	  0.857  __ipipe_do_IRQ+0x10 (__ipipe_do_sync_stage+0x1e8)
frozen::    #func                 -53	  1.000  handle_IRQ+0x10 (__ipipe_do_IRQ+0x40)
frozen::    #func                 -52	  0.857  irq_enter+0x10 (handle_IRQ+0x54)
frozen::    #func                 -51	  0.857  rcu_irq_enter+0x10 (irq_enter+0x28)
frozen::    #func                 -50	  0.857  ipipe_test_and_stall_root+0x10 (rcu_irq_enter+0x18)
frozen::    #func                 -49	  1.000  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
frozen::|   #begin   0x80000001   -48+   1.285  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
frozen::|   #end     0x80000001   -47+   1.142  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
frozen::|   #begin   0x90000000   -46	  0.857  __irq_svc+0x44 (ipipe_root_only+0xa8)
frozen::|   #func                 -45	  1.000  gic_handle_irq+0x10 (__irq_svc+0x58)
frozen::|   #func                 -44	  0.857  irq_find_mapping+0x14 (gic_handle_irq+0x30)
frozen::|   #func                 -43+   1.142  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
frozen::|   #begin   0x0000001b   -42	  0.857  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
frozen::|   #func                 -41	  1.000  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
frozen::|   #func                 -40	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
frozen::|   #func                 -39	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
frozen::|   #func                 -38	  0.857  __ipipe_ack_hrtimer_irq+0x10 (__ipipe_dispatch_irq+0x70)
frozen::|   #func                 -37	  1.000  __ipipe_ack_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x60)
frozen::|   #func                 -36	  0.857  gic_hold_irq+0x10 (__ipipe_ack_fasteoi_irq+0x24)
frozen::|   #func                 -35+   1.142  __ipipe_spin_lock_irqsave+0x10 (gic_hold_irq+0x34)
frozen::|   #func                 -34+   1.142  __ipipe_spin_unlock_irqrestore+0x10 (gic_hold_irq+0x98)
frozen::|   #func                 -33	  0.857  arch_itimer_ack_virt+0x10 (__ipipe_ack_hrtimer_irq+0x70)
frozen::|   #func                 -32	  1.000  __ipipe_end_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x88)
frozen::|   #func                 -31	  0.714  gic_release_irq+0x10 (__ipipe_end_fasteoi_irq+0x2c)
frozen::|   #func                 -31+   1.285  __ipipe_spin_lock_irqsave+0x10 (gic_release_irq+0x34)
frozen::|   #func                 -29+   1.857  __ipipe_spin_unlock_irqrestore+0x10 (gic_release_irq+0x74)
frozen::|  #*func                 -27+   1.142  xnintr_clock_handler+0x14 [xeno_nucleus] (__ipipe_dispatch_irq+0x270)
frozen::|  #*func                 -26	  0.857  xntimer_tick_aperiodic+0x14 [xeno_nucleus] (xnintr_clock_handler+0x1e0 [xeno_nucleus])
frozen::|  #*func                 -25	  0.857  xnthread_timeout_handler+0x10 [xeno_nucleus] (xntimer_tick_aperiodic+0x13c [xeno_nucleus])
frozen::|  #*func                 -25	  1.000  xnpod_resume_thread+0x14 [xeno_nucleus] (xnthread_timeout_handler+0x34 [xeno_nucleus])
frozen::|  #*[ 5197] MAC Poll 0   -24+   1.285  xnpod_resume_thread+0x124 [xeno_nucleus] (xnthread_timeout_handler+0x34 [xeno_nucleus])
frozen::|  #*func                 -22	  0.857  xntimer_next_local_shot+0x10 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
frozen::|  #*event   tick@11992   -21	  0.857  xntimer_next_local_shot+0xb4 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
frozen::|  #*func                 -21	  1.000  ipipe_timer_set+0x10 (xntimer_next_local_shot+0xbc [xeno_nucleus])
frozen::|  #*func                 -20+   1.142  arch_timer_set_next_event_virt+0x10 (ipipe_timer_set+0x7c)
frozen::|  #*func                 -18+   1.428  __xnpod_schedule+0x14 [xeno_nucleus] (xnintr_clock_handler+0x408 [xeno_nucleus])
frozen::|  #*[    0] -<?>-   -1   -17	  1.000  __xnpod_schedule+0x194 [xeno_nucleus] (xnintr_clock_handler+0x408 [xeno_nucleus])
frozen::|  #*func                 -16	  1.000  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
frozen::|  #*func                 -15	  0.857  omap4_mute_pic+0x10 (__xnpod_schedule+0x714 [xeno_nucleus])
frozen::|  #*func                 -14+   1.142  gic_mute+0x10 (omap4_mute_pic+0x1c)
frozen::|  #*func                 -13+   2.000  _get_gpio_irqbank_mask+0x10 (omap4_mute_pic+0x58)
frozen::|  #*[ 5197] MAC Poll 0   -11+   1.428  __xnpod_schedule+0x604 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
frozen::|  #*func                 -10+   1.142  __ipipe_restore_head+0x10 (xnpod_suspend_thread+0x1c4 [xeno_nucleus])
frozen::|  +*end     0x80000000    -8	  1.000  __ipipe_restore_head+0xd8 (xnpod_suspend_thread+0x1c4 [xeno_nucleus])
frozen::|  +*begin   0x90000000    -7	  1.000  __irq_svc+0x44 (__ipipe_restore_head+0xdc)
frozen::|  +*func                  -6	  0.857  gic_handle_irq+0x10 (__irq_svc+0x58)
frozen::|  +*func                  -6	  1.000  irq_find_mapping+0x14 (gic_handle_irq+0x30)
frozen::|  +*func                  -5	  0.857  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
frozen::|  +*begin   0x00000043    -4	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
frozen::|  +*func                  -3	  0.857  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
frozen::|  +*func                  -2	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
frozen::|  +*func                  -1+   1.285  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
frozen:<|  +*func                   0	  1.142  gpio_irq_handler+0x14 (__ipipe_dispatch_irq+0x70)
frozen: |  +*func                   1	  1.571  irq_to_desc+0x10 (gpio_irq_handler+0x38)
frozen: |  +*func                   2	  1.000  irq_find_mapping+0x14 (gpio_irq_handler+0x190)
frozen: |  +*begin   0x0000018e     3	  0.857  gpio_irq_handler+0x198 (__ipipe_dispatch_irq+0x70)
frozen: |  +*func                   4	  0.857  __ipipe_dispatch_irq+0x14 (gpio_irq_handler+0x1a4)
frozen: |  +*func                   5	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
frozen: |  +*func                   6	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
frozen: |  +*func                   7	  1.142  __ipipe_ack_level_irq+0x10 (__ipipe_dispatch_irq+0x70)
frozen: |  +*func                   8	  0.857  gpio_mask_ack_irq+0x10 (__ipipe_ack_level_irq+0x30)
frozen: |  +*func                   9	  3.428  __ipipe_spin_lock_irqsave+0x10 (gpio_mask_ack_irq+0x30)
frozen: |  #*func                  13	  0.000  __ipipe_spin_unlock_irqrestore+0x10 (gpio_mask_ack_irq+0x210)
max:I-pipe worst-case tracing service on 3.12-1-am5726/ipipe release #2
max:-------------------------------------------------------------
max:CPU: 0, Begin: 1137045851 cycles, Trace Points: 3 (-10/+1), Length: 617 us
max:Calibrated minimum trace-point overhead: 0.428 us
max: +----- Hard IRQs ('|': locked)
max: |+-- Xenomai
max: ||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
max: |||			  +---------- Delay flag ('+': > 1 us, '!': > 10 us)
max: |||			  |	   +- NMI noise ('N')
max: |||			  |	   |
max:	  Type	  User Val.   Time    Delay  Function (Parent)
max:     #func                 -10	  1.000  tick_check_broadcast_expired+0x10 (cpu_startup_entry+0x40)
max:     #func                  -9	  0.857  rcu_idle_enter+0x10 (cpu_startup_entry+0x58)
max:     #func                  -8	  0.857  ipipe_test_and_stall_root+0x10 (rcu_idle_enter+0x18)
max:     #func                  -7	  1.000  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
max: |   #begin   0x80000001    -6	  1.285  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
max: |   #end     0x80000001    -5	  1.000  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
max: |   #begin   0x80000001    -4	  1.142  ipipe_test_and_stall_root+0x84 (rcu_idle_enter+0x18)
max: |   #end     0x80000001    -3	  1.000  ipipe_test_and_stall_root+0x70 (rcu_idle_enter+0x18)
max:     #func                  -2	  1.000  rcu_eqs_enter_common.isra.47+0x14 (rcu_idle_enter+0x84)
max:     #func                  -1	  1.000  arch_cpu_idle+0x10 (cpu_startup_entry+0x5c)
max:>|   #begin   0x80000000     0	  1.000  arch_cpu_idle+0xa4 (cpu_startup_entry+0x5c)
max::|   +func                   1! 616.428  omap_default_idle+0x10 (arch_cpu_idle+0x90)
max:<|   +end     0x80000000   617	  1.142  omap_default_idle+0x40 (arch_cpu_idle+0x90)
max: |   +begin   0x90000000   618	  0.000  __irq_svc+0x44 (omap_default_idle+0x44)
post_trace_points:10
pre_trace_points:10
trigger:gpio_irq_handler+0x0/0x298
verbose:1

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Mon, Nov 17, 2014 at 04:47:34PM -0500, Lennart Sorensen wrote:
> On Mon, Nov 17, 2014 at 09:27:54PM +0100, Gilles Chanteperdrix wrote:
> > On Mon, Nov 17, 2014 at 03:24:25PM -0500, Lennart Sorensen wrote:
> > > On Mon, Nov 17, 2014 at 09:14:35PM +0100, Gilles Chanteperdrix wrote:
> > > > Well, have you tried triggering an I-pipe tracer trace to see what
> > > > happens in the interval?
> > > 
> > > I have never used the tracer. I suppose I should learn how.
> > 
> > It is not very complicated. I have already been told on this list
> > that it was not well documented. I do not think so, but I let you
> > judge of that.
> > 
> > http://xenomai.org/2014/06/using-the-i-pipe-tracer/
> 
> So here is what I got triggering a couple of times on the IRQ.  Not
> entirely sure how to make sense of it, although there is one huge number.
> 
> back_trace_points:100
> enable:1
> frozen:I-pipe frozen back-tracing service on 3.12-1-am5726/ipipe release #2
> frozen:------------------------------------------------------------
> frozen:CPU: 0, Freeze: 2415647132 cycles, Trace Points: 100 (+10)
> frozen:Calibrated minimum trace-point overhead: 0.428 us
> frozen: +----- Hard IRQs ('|': locked)
> frozen: |+-- Xenomai
> frozen: ||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
> frozen: |||			  +---------- Delay flag ('+': > 1 us, '!': > 10 us)
> frozen: |||			  |	   +- NMI noise ('N')
> frozen: |||			  |	   |
> frozen:	  Type	  User Val.   Time    Delay  Function (Parent)
> frozen::    #func                -662	  0.857  arch_cpu_idle_enter+0x10 (cpu_startup_entry+0xb8)
> frozen::    #func                -661	  1.000  ledtrig_cpu+0x10 (arch_cpu_idle_enter+0x1c)
> frozen::    #func                -660	  1.000  led_trigger_event+0x10 (ledtrig_cpu+0x58)
> frozen::    #func                -659+   1.285  _raw_read_lock+0x10 (led_trigger_event+0x30)
> frozen::    #func                -658	  0.857  tick_check_broadcast_expired+0x10 (cpu_startup_entry+0x40)
> frozen::    #func                -657	  1.000  rcu_idle_enter+0x10 (cpu_startup_entry+0x58)
> frozen::    #func                -656	  0.857  ipipe_test_and_stall_root+0x10 (rcu_idle_enter+0x18)
> frozen::    #func                -655	  0.857  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
> frozen::|   #begin   0x80000001  -654+   1.428  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
> frozen::|   #end     0x80000001  -653	  1.000  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
> frozen::|   #begin   0x80000001  -652	  1.000  ipipe_test_and_stall_root+0x84 (rcu_idle_enter+0x18)
> frozen::|   #end     0x80000001  -651	  1.000  ipipe_test_and_stall_root+0x70 (rcu_idle_enter+0x18)
> frozen::    #func                -650	  1.000  rcu_eqs_enter_common.isra.47+0x14 (rcu_idle_enter+0x84)
> frozen::    #func                -649	  1.000  arch_cpu_idle+0x10 (cpu_startup_entry+0x5c)
> frozen::|   #begin   0x80000000  -648	  1.000  arch_cpu_idle+0xa4 (cpu_startup_entry+0x5c)
> frozen::|   +func                -647! 555.142 omap_default_idle+0x10 (arch_cpu_idle+0x90)      <-- What ever is
> that?  That looks huge.

As the name suggests, it means that the CPU remains idle for 500us.
You know, when the cpu load is not 100%, this is what the cpu is
doing the rest of the time, executing the wfi instruction to wait
for the next interrupt.

> frozen::|   +end     0x80000000   -92+   1.142 omap_default_idle+0x40 (arch_cpu_idle+0x90)
  (...)
> frozen::|  +*func                  -6	  0.857  gic_handle_irq+0x10 (__irq_svc+0x58)
> frozen::|  +*func                  -6	  1.000  irq_find_mapping+0x14 (gic_handle_irq+0x30)
> frozen::|  +*func                  -5	  0.857  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
> frozen::|  +*begin   0x00000043    -4	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
> frozen::|  +*func                  -3	  0.857  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
> frozen::|  +*func                  -2	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> frozen::|  +*func                  -1+   1.285  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> frozen:<|  +*func                   0	  1.142  gpio_irq_handler+0x14 (__ipipe_dispatch_irq+0x70)
> frozen: |  +*func                   1	  1.571  irq_to_desc+0x10 (gpio_irq_handler+0x38)
> frozen: |  +*func                   2	  1.000  irq_find_mapping+0x14 (gpio_irq_handler+0x190)
> frozen: |  +*begin   0x0000018e     3	  0.857  gpio_irq_handler+0x198 (__ipipe_dispatch_irq+0x70)
> frozen: |  +*func                   4	  0.857  __ipipe_dispatch_irq+0x14 (gpio_irq_handler+0x1a4)
> frozen: |  +*func                   5	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> frozen: |  +*func                   6	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> frozen: |  +*func                   7	  1.142  __ipipe_ack_level_irq+0x10 (__ipipe_dispatch_irq+0x70)
> frozen: |  +*func                   8	  0.857  gpio_mask_ack_irq+0x10 (__ipipe_ack_level_irq+0x30)
> frozen: |  +*func                   9	  3.428  __ipipe_spin_lock_irqsave+0x10 (gpio_mask_ack_irq+0x30)
> frozen: |  #*func                  13	  0.000
> __ipipe_spin_unlock_irqrestore+0x10 (gpio_mask_ack_irq+0x210)


So, the end of the trace is executing gpio_mask_ack_irq. Trace is
to short. It stops just when things were beginning to become
interesting. Please increase the number of trace points.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Mon, Nov 17, 2014 at 10:54:58PM +0100, Gilles Chanteperdrix wrote:
> On Mon, Nov 17, 2014 at 04:47:34PM -0500, Lennart Sorensen wrote:
> > On Mon, Nov 17, 2014 at 09:27:54PM +0100, Gilles Chanteperdrix wrote:
> > > On Mon, Nov 17, 2014 at 03:24:25PM -0500, Lennart Sorensen wrote:
> > > > On Mon, Nov 17, 2014 at 09:14:35PM +0100, Gilles Chanteperdrix wrote:
> > > > > Well, have you tried triggering an I-pipe tracer trace to see what
> > > > > happens in the interval?
> > > > 
> > > > I have never used the tracer. I suppose I should learn how.
> > > 
> > > It is not very complicated. I have already been told on this list
> > > that it was not well documented. I do not think so, but I let you
> > > judge of that.
> > > 
> > > http://xenomai.org/2014/06/using-the-i-pipe-tracer/
> > 
> > So here is what I got triggering a couple of times on the IRQ.  Not
> > entirely sure how to make sense of it, although there is one huge number.
> > 
> > back_trace_points:100
> > enable:1
> > frozen:I-pipe frozen back-tracing service on 3.12-1-am5726/ipipe release #2
> > frozen:------------------------------------------------------------
> > frozen:CPU: 0, Freeze: 2415647132 cycles, Trace Points: 100 (+10)
> > frozen:Calibrated minimum trace-point overhead: 0.428 us
> > frozen: +----- Hard IRQs ('|': locked)
> > frozen: |+-- Xenomai
> > frozen: ||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
> > frozen: |||			  +---------- Delay flag ('+': > 1 us, '!': > 10 us)
> > frozen: |||			  |	   +- NMI noise ('N')
> > frozen: |||			  |	   |
> > frozen:	  Type	  User Val.   Time    Delay  Function (Parent)
> > frozen::    #func                -662	  0.857  arch_cpu_idle_enter+0x10 (cpu_startup_entry+0xb8)
> > frozen::    #func                -661	  1.000  ledtrig_cpu+0x10 (arch_cpu_idle_enter+0x1c)
> > frozen::    #func                -660	  1.000  led_trigger_event+0x10 (ledtrig_cpu+0x58)
> > frozen::    #func                -659+   1.285  _raw_read_lock+0x10 (led_trigger_event+0x30)
> > frozen::    #func                -658	  0.857  tick_check_broadcast_expired+0x10 (cpu_startup_entry+0x40)
> > frozen::    #func                -657	  1.000  rcu_idle_enter+0x10 (cpu_startup_entry+0x58)
> > frozen::    #func                -656	  0.857  ipipe_test_and_stall_root+0x10 (rcu_idle_enter+0x18)
> > frozen::    #func                -655	  0.857  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
> > frozen::|   #begin   0x80000001  -654+   1.428  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
> > frozen::|   #end     0x80000001  -653	  1.000  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
> > frozen::|   #begin   0x80000001  -652	  1.000  ipipe_test_and_stall_root+0x84 (rcu_idle_enter+0x18)
> > frozen::|   #end     0x80000001  -651	  1.000  ipipe_test_and_stall_root+0x70 (rcu_idle_enter+0x18)
> > frozen::    #func                -650	  1.000  rcu_eqs_enter_common.isra.47+0x14 (rcu_idle_enter+0x84)
> > frozen::    #func                -649	  1.000  arch_cpu_idle+0x10 (cpu_startup_entry+0x5c)
> > frozen::|   #begin   0x80000000  -648	  1.000  arch_cpu_idle+0xa4 (cpu_startup_entry+0x5c)
> > frozen::|   +func                -647! 555.142 omap_default_idle+0x10 (arch_cpu_idle+0x90)      <-- What ever is
> > that?  That looks huge.
> 
> As the name suggests, it means that the CPU remains idle for 500us.
> You know, when the cpu load is not 100%, this is what the cpu is
> doing the rest of the time, executing the wfi instruction to wait
> for the next interrupt.
> 
> > frozen::|   +end     0x80000000   -92+   1.142 omap_default_idle+0x40 (arch_cpu_idle+0x90)
>   (...)
> > frozen::|  +*func                  -6	  0.857  gic_handle_irq+0x10 (__irq_svc+0x58)
> > frozen::|  +*func                  -6	  1.000  irq_find_mapping+0x14 (gic_handle_irq+0x30)
> > frozen::|  +*func                  -5	  0.857  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
> > frozen::|  +*begin   0x00000043    -4	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
> > frozen::|  +*func                  -3	  0.857  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
> > frozen::|  +*func                  -2	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> > frozen::|  +*func                  -1+   1.285  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> > frozen:<|  +*func                   0	  1.142  gpio_irq_handler+0x14 (__ipipe_dispatch_irq+0x70)
> > frozen: |  +*func                   1	  1.571  irq_to_desc+0x10 (gpio_irq_handler+0x38)
> > frozen: |  +*func                   2	  1.000  irq_find_mapping+0x14 (gpio_irq_handler+0x190)
> > frozen: |  +*begin   0x0000018e     3	  0.857  gpio_irq_handler+0x198 (__ipipe_dispatch_irq+0x70)
> > frozen: |  +*func                   4	  0.857  __ipipe_dispatch_irq+0x14 (gpio_irq_handler+0x1a4)
> > frozen: |  +*func                   5	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> > frozen: |  +*func                   6	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> > frozen: |  +*func                   7	  1.142  __ipipe_ack_level_irq+0x10 (__ipipe_dispatch_irq+0x70)
> > frozen: |  +*func                   8	  0.857  gpio_mask_ack_irq+0x10 (__ipipe_ack_level_irq+0x30)
> > frozen: |  +*func                   9	  3.428  __ipipe_spin_lock_irqsave+0x10 (gpio_mask_ack_irq+0x30)
> > frozen: |  #*func                  13	  0.000
> > __ipipe_spin_unlock_irqrestore+0x10 (gpio_mask_ack_irq+0x210)
> 
> 
> So, the end of the trace is executing gpio_mask_ack_irq. Trace is
> to short. It stops just when things were beginning to become
> interesting. Please increase the number of trace points.

Good to know.  Will increase it.

I increases it to 100 and get this:

I-pipe frozen back-tracing service on 3.12-1-am5726/ipipe release #2
------------------------------------------------------------
CPU: 0, Freeze: 2472048413 cycles, Trace Points: 100 (+100)
Calibrated minimum trace-point overhead: 0.428 us

 +----- Hard IRQs ('|': locked)
 |+-- Xenomai
 ||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
 |||			  +---------- Delay flag ('+': > 1 us, '!': > 10 us)
 |||			  |	   +- NMI noise ('N')
 |||			  |	   |
	  Type	  User Val.   Time    Delay  Function (Parent)
:    #func                -104	  0.857  internal_add_timer+0x10 (mod_timer+0x10c)
:    #func                -103	  1.000  __internal_add_timer+0x10 (internal_add_timer+0x20)
:    #func                -102	  0.857  __ipipe_spin_unlock_debug+0x10 (mod_timer+0x114)
:    #func                -102	  1.000  _raw_spin_unlock_irqrestore+0x10 (mod_timer+0x120)
:    #func                -101	  1.000  ipipe_unstall_root+0x10 (_raw_spin_unlock_irqrestore+0x38)
:|   #begin   0x80000000  -100	  1.000  ipipe_unstall_root+0x90 (_raw_spin_unlock_irqrestore+0x38)
:|   #func                 -99+   1.428  ipipe_root_only+0x14 (ipipe_unstall_root+0x24)
:|   +end     0x80000000   -97	  1.000  ipipe_unstall_root+0x7c (_raw_spin_unlock_irqrestore+0x38)
:    +func                 -96	  1.000  _raw_spin_lock_irq+0x10 (run_timer_softirq+0x1f4)
:    +func                 -95	  1.000  ipipe_stall_root+0x10 (_raw_spin_lock_irq+0x1c)
:    +func                 -94	  0.857  ipipe_root_only+0x14 (ipipe_stall_root+0x18)
:|   +begin   0x80000001   -93+   1.285  ipipe_root_only+0xb8 (ipipe_stall_root+0x18)
:|   +end     0x80000001   -92	  1.000  ipipe_root_only+0xa4 (ipipe_stall_root+0x18)
:|   +begin   0x80000001   -91+   1.142  ipipe_stall_root+0x7c (_raw_spin_lock_irq+0x1c)
:|   #end     0x80000001   -90+   1.142  ipipe_stall_root+0x6c (_raw_spin_lock_irq+0x1c)
:    #func                 -89	  1.000  ipipe_unstall_root+0x10 (run_timer_softirq+0x1d0)
:|   #begin   0x80000000   -88	  0.857  ipipe_unstall_root+0x90 (run_timer_softirq+0x1d0)
:|   #func                 -87+   1.428  ipipe_root_only+0x14 (ipipe_unstall_root+0x24)
:|   +end     0x80000000   -85+   1.142  ipipe_unstall_root+0x7c (run_timer_softirq+0x1d0)
:    +func                 -84	  0.857  rcu_bh_qs+0x10 (__do_softirq+0x134)
:    +func                 -83	  0.857  ipipe_stall_root+0x10 (__do_softirq+0x148)
:    +func                 -83	  1.000  ipipe_root_only+0x14 (ipipe_stall_root+0x18)
:|   +begin   0x80000001   -82+   1.285  ipipe_root_only+0xb8 (ipipe_stall_root+0x18)
:|   +end     0x80000001   -80	  1.000  ipipe_root_only+0xa4 (ipipe_stall_root+0x18)
:|   +begin   0x80000001   -79+   1.142  ipipe_stall_root+0x7c (__do_softirq+0x148)
:|   #end     0x80000001   -78	  1.000  ipipe_stall_root+0x6c (__do_softirq+0x148)
:    #func                 -77	  1.000  __local_bh_enable+0x10 (__do_softirq+0x1a8)
:    #func                 -76	  0.857  ipipe_test_root+0x10 (__local_bh_enable+0x40)
:|   #begin   0x80000001   -75+   1.142  ipipe_test_root+0x78 (__local_bh_enable+0x40)
:|   #end     0x80000001   -74	  1.000  ipipe_test_root+0x64 (__local_bh_enable+0x40)
:    #func                 -73	  0.857  ipipe_root_only+0x14 (__local_bh_enable+0x4c)
:|   #begin   0x80000001   -72+   1.285  ipipe_root_only+0xb8 (__local_bh_enable+0x4c)
:|   #end     0x80000001   -71	  1.000  ipipe_root_only+0xa4 (__local_bh_enable+0x4c)
:    #func                 -70	  1.000  rcu_irq_exit+0x10 (irq_exit+0x84)
:    #func                 -69	  0.857  ipipe_test_and_stall_root+0x10 (rcu_irq_exit+0x18)
:    #func                 -68	  1.000  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
:|   #begin   0x80000001   -67+   1.285  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
:|   #end     0x80000001   -66	  1.000  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
:|   #begin   0x80000001   -65	  1.000  ipipe_test_and_stall_root+0x84 (rcu_irq_exit+0x18)
:|   #end     0x80000001   -64	  1.000  ipipe_test_and_stall_root+0x70 (rcu_irq_exit+0x18)
:    #func                 -63+   1.142  rcu_eqs_enter_common.isra.47+0x14 (rcu_irq_exit+0x84)
:|   #begin   0x80000000   -62+   1.285  __ipipe_do_sync_stage+0x288 (__ipipe_do_sync_pipeline+0x140)
:|   +end     0x0000001b   -60	  0.857  __ipipe_grab_irq+0x7c (gic_handle_irq+0x38)
:|   +func                 -60	  0.857  __ipipe_exit_irq+0x10 (__ipipe_grab_irq+0x84)
:|   +func                 -59+   1.142  __ipipe_check_root_interruptible+0x10 (__irq_svc+0x5c)
:|   +func                 -58+   1.142  ipipe_test_root+0x10 (__ipipe_check_root_interruptible+0x60)
:|   +func                 -56	  1.000  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_fast_svc_irq_exit+0x4)
:|   +end     0x90000000   -55	  1.000  __ipipe_fast_svc_irq_exit+0x18 (omap_default_idle+0x44)
:    +func                 -54	  1.000  ipipe_unstall_root+0x10 (arch_cpu_idle+0x94)
:|   +begin   0x80000000   -53	  0.857  ipipe_unstall_root+0x90 (arch_cpu_idle+0x94)
:|   +func                 -53+   1.571  ipipe_root_only+0x14 (ipipe_unstall_root+0x24)
:|   +end     0x80000000   -51	  1.000  ipipe_unstall_root+0x7c (arch_cpu_idle+0x94)
:    +func                 -50	  0.857  ipipe_test_root+0x10 (cpu_startup_entry+0x60)
:|   +begin   0x80000001   -49+   1.142  ipipe_test_root+0x78 (cpu_startup_entry+0x60)
:|   +end     0x80000001   -48+   1.142  ipipe_test_root+0x64 (cpu_startup_entry+0x60)
:|   +begin   0x90000000   -47	  1.000  __irq_svc+0x44 (ipipe_test_root+0x68)
:|   +func                 -46	  0.857  gic_handle_irq+0x10 (__irq_svc+0x58)
:|   +func                 -45	  1.000  irq_find_mapping+0x14 (gic_handle_irq+0x30)
:|   +func                 -44	  1.000  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
:|   +begin   0x0000001b   -43	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
:|   +func                 -42	  1.000  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
:|   +func                 -41	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
:|   +func                 -40	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
:|   +func                 -39	  1.000  __ipipe_ack_hrtimer_irq+0x10 (__ipipe_dispatch_irq+0x70)
:|   +func                 -38	  1.000  __ipipe_ack_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x60)
:|   +func                 -37	  0.857  gic_hold_irq+0x10 (__ipipe_ack_fasteoi_irq+0x24)
:|   +func                 -36+   1.142  __ipipe_spin_lock_irqsave+0x10 (gic_hold_irq+0x34)
:|   #func                 -35+   1.285  __ipipe_spin_unlock_irqrestore+0x10 (gic_hold_irq+0x98)
:|   +func                 -34	  1.000  arch_itimer_ack_virt+0x10 (__ipipe_ack_hrtimer_irq+0x70)
:|   +func                 -33	  0.857  __ipipe_end_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x88)
:|   +func                 -32	  1.000  gic_release_irq+0x10 (__ipipe_end_fasteoi_irq+0x2c)
:|   +func                 -31+   1.142  __ipipe_spin_lock_irqsave+0x10 (gic_release_irq+0x34)
:|   #func                 -30+   1.857  __ipipe_spin_unlock_irqrestore+0x10 (gic_release_irq+0x74)
:|  # func                 -28+   1.285  xnintr_clock_handler+0x14 [xeno_nucleus] (__ipipe_dispatch_irq+0x270)
:|  # func                 -27	  0.857  xntimer_tick_aperiodic+0x14 [xeno_nucleus] (xnintr_clock_handler+0x1e0 [xeno_nucleus])
:|  # func                 -26	  0.857  xnthread_timeout_handler+0x10 [xeno_nucleus] (xntimer_tick_aperiodic+0x13c [xeno_nucleus])
:|  # func                 -25+   1.142  xnpod_resume_thread+0x14 [xeno_nucleus] (xnthread_timeout_handler+0x34 [xeno_nucleus])
:|  # [ 5285] MAC Poll 0   -24+   1.285  xnpod_resume_thread+0x124 [xeno_nucleus] (xnthread_timeout_handler+0x34 [xeno_nucleus])
:|  # func                 -22	  0.857  xntimer_next_local_shot+0x10 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
:|  # event   tick@16049   -22	  0.857  xntimer_next_local_shot+0xb4 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
:|  # func                 -21+   1.142  ipipe_timer_set+0x10 (xntimer_next_local_shot+0xbc [xeno_nucleus])
:|  # func                 -20+   1.285  arch_timer_set_next_event_virt+0x10 (ipipe_timer_set+0x7c)
:|  # func                 -18+   1.285  __xnpod_schedule+0x14 [xeno_nucleus] (xnintr_clock_handler+0x408 [xeno_nucleus])
:|  # [    0] -<?>-   -1   -17	  1.000  __xnpod_schedule+0x194 [xeno_nucleus] (xnintr_clock_handler+0x408 [xeno_nucleus])
:|  # func                 -16	  1.000  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
:|  # func                 -15	  0.857  omap4_mute_pic+0x10 (__xnpod_schedule+0x714 [xeno_nucleus])
:|  # func                 -14+   1.285  gic_mute+0x10 (omap4_mute_pic+0x1c)
:|  # func                 -13+   1.857  _get_gpio_irqbank_mask+0x10 (omap4_mute_pic+0x58)
:|  # [ 5285] MAC Poll 0   -11+   1.571  __xnpod_schedule+0x604 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
:|  # func                  -9	  1.000  __ipipe_restore_head+0x10 (xnpod_suspend_thread+0x1c4 [xeno_nucleus])
:|  + end     0x80000000    -8	  1.000  __ipipe_restore_head+0xd8 (xnpod_suspend_thread+0x1c4 [xeno_nucleus])
:|  + begin   0x90000000    -7	  1.000  __irq_svc+0x44 (__ipipe_restore_head+0xdc)
:|  + func                  -6	  1.000  gic_handle_irq+0x10 (__irq_svc+0x58)
:|  + func                  -5	  0.857  irq_find_mapping+0x14 (gic_handle_irq+0x30)
:|  + func                  -5	  1.000  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
:|  + begin   0x00000043    -4	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
:|  + func                  -3	  0.857  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
:|  + func                  -2	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
:|  + func                  -1+   1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
<|  + func                   0	  1.142  gpio_irq_handler+0x14 (__ipipe_dispatch_irq+0x70)
 |  + func                   1	  1.571  irq_to_desc+0x10 (gpio_irq_handler+0x38)
 |  + func                   2	  1.000  irq_find_mapping+0x14 (gpio_irq_handler+0x190)
 |  + begin   0x0000018e     3	  0.857  gpio_irq_handler+0x198 (__ipipe_dispatch_irq+0x70)
 |  + func                   4	  0.857  __ipipe_dispatch_irq+0x14 (gpio_irq_handler+0x1a4)
 |  + func                   5	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
 |  + func                   6	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
 |  + func                   7	  1.000  __ipipe_ack_level_irq+0x10 (__ipipe_dispatch_irq+0x70)
 |  + func                   8	  1.000  gpio_mask_ack_irq+0x10 (__ipipe_ack_level_irq+0x30)
 |  + func                   9	  3.571  __ipipe_spin_lock_irqsave+0x10 (gpio_mask_ack_irq+0x30)
 |  # func                  13	  1.714  __ipipe_spin_unlock_irqrestore+0x10 (gpio_mask_ack_irq+0x210)
 |  + func                  15	  1.142  __ipipe_set_irq_pending+0x10 (__ipipe_dispatch_irq+0x490)
 |  + end     0x0000018e    16	  1.428  gpio_irq_handler+0x1ac (__ipipe_dispatch_irq+0x70)
 |  + func                  17	  0.857  gic_eoi_irq+0x10 (gpio_irq_handler+0x168)
 |  + func                  18	  1.142  __ipipe_spin_lock_irqsave+0x10 (gic_eoi_irq+0x24)
 |  # func                  19	  1.714  __ipipe_spin_unlock_irqrestore+0x10 (gic_eoi_irq+0x48)
 |  + func                  21	  1.142  __ipipe_do_sync_stage+0x14 (__ipipe_dispatch_irq+0x3d4)
 |  # func                  22	  1.428  xnintr_irq_handler+0x14 [xeno_nucleus] (__ipipe_do_sync_stage+0x1e8)
 |  # func                  23	  1.000  rt_intr_handler+0x10 [xeno_native] (xnintr_irq_handler+0x11c [xeno_nucleus])
 |  # func                  24	  1.285  xnsynch_flush+0x14 [xeno_nucleus] (rt_intr_handler+0x3c [xeno_native])
 |  # func                  26	  1.428  xnpod_resume_thread+0x14 [xeno_nucleus] (xnsynch_flush+0x160 [xeno_nucleus])
 |  # [ 5284] 000000 257    27	  2.142  xnpod_resume_thread+0x124 [xeno_nucleus] (xnsynch_flush+0x160 [xeno_nucleus])
 |  # func                  29	  1.428  __xnpod_schedule+0x14 [xeno_nucleus] (xnintr_irq_handler+0x318 [xeno_nucleus])
 |  # [ 5285] MAC Poll 0    31	  0.857  __xnpod_schedule+0x194 [xeno_nucleus] (xnintr_irq_handler+0x318 [xeno_nucleus])
 |  # func                  32	  2.000  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
 |  # [ 5284] 000000 257    34	  3.142  __xnpod_schedule+0x604 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
 |  # func                  37	  1.142  __ipipe_restore_head+0x10 (__rt_intr_wait+0x210 [xeno_native])
 |  + end     0x80000000    38	  1.714  __ipipe_restore_head+0xd8 (__rt_intr_wait+0x210 [xeno_native])
 |  + begin   0x80000001    40	  1.428  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
 |  + end     0x80000001    41	  0.857  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
 |  + func                  42	  1.000  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
 |  + end     0x90000000    43	  2.142  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0ba30>)
 |  + begin   0x90000000    45	  1.000  vector_swi+0x3c (<b6f0cb12>)
    + func                  46	  0.857  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
 |  + begin   0x80000001    47	  1.428  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
 |  + end     0x80000001    48	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
    + func                  49	  0.857  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)
 |  + begin   0x80000001    50	  1.000  ipipe_syscall_hook+0x9c (__ipipe_notify_syscall+0xc0)
 |  + end     0x80000001    51	  1.142  ipipe_syscall_hook+0x70 (__ipipe_notify_syscall+0xc0)
    + func                  52	  1.000  hisyscall_event+0x14 [xeno_nucleus] (ipipe_syscall_hook+0x90)
    + func                  53	  1.000  __rt_sem_v+0x14 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
    + func                  54	  1.428  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_sem_v+0x68 [xeno_native])
    + func                  56	  1.000  rt_sem_v+0x14 [xeno_native] (__rt_sem_v+0x74 [xeno_native])
 |  + begin   0x80000000    57	  1.857  rt_sem_v+0x20c [xeno_native] (__rt_sem_v+0x74 [xeno_native])
 |  # func                  58	  1.285  xnsynch_wakeup_one_sleeper+0x14 [xeno_nucleus] (rt_sem_v+0x218 [xeno_native])
 |  # func                  60	  1.428  xnpod_resume_thread+0x14 [xeno_nucleus] (xnsynch_wakeup_one_sleeper+0x158 [xeno_nucleus])
 |  # [ 5283] M88E6xx 90    61	  1.285  xnpod_resume_thread+0x124 [xeno_nucleus] (xnsynch_wakeup_one_sleeper+0x158 [xeno_nucleus])
 |  # func                  62	  1.428  __xnpod_schedule+0x14 [xeno_nucleus] (rt_sem_v+0x268 [xeno_native])
 |  # [ 5284] 000000 257    64	  0.857  __xnpod_schedule+0x194 [xeno_nucleus] (rt_sem_v+0x268 [xeno_native])
 |  # func                  65	  1.571  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
 |  # func                  66	  1.000  __ipipe_restore_head+0x10 (rt_sem_v+0x168 [xeno_native])
 |  + end     0x80000000    67	  1.142  __ipipe_restore_head+0xd8 (rt_sem_v+0x168 [xeno_native])
 |  + begin   0x80000001    68	  1.142  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
 |  + end     0x80000001    70	  0.857  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
 |  + func                  70	  0.857  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
 |  + end     0x90000000    71	  2.000  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0cb16>)
 |  + begin   0x90000000    73	  1.000  vector_swi+0x3c (<b6f0ba2c>)
    + func                  74	  0.857  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
 |  + begin   0x80000001    75	  1.285  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
 |  + end     0x80000001    76	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
    + func                  77	  1.000  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)
 |  + begin   0x80000001    78	  1.000  ipipe_syscall_hook+0x9c (__ipipe_notify_syscall+0xc0)
 |  + end     0x80000001    79	  0.857  ipipe_syscall_hook+0x70 (__ipipe_notify_syscall+0xc0)
    + func                  80	  1.000  hisyscall_event+0x14 [xeno_nucleus] (ipipe_syscall_hook+0x90)
    + func                  81	  1.000  __rt_intr_wait+0x14 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
 |  + begin   0x80000000    82	  1.142  __rt_intr_wait+0xc8 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
 |  # func                  83	  1.000  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_intr_wait+0x19c [xeno_native])
 |  # func                  84	  1.000  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_intr_wait+0x1ac [xeno_native])
 |  # func                  85	  0.857  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_intr_wait+0x2a8 [xeno_native])
 |  # func                  86	  1.285  xnsynch_sleep_on+0x14 [xeno_nucleus] (__rt_intr_wait+0x30c [xeno_native])
 |  # func                  87	  1.285  xnpod_suspend_thread+0x14 [xeno_nucleus] (xnsynch_sleep_on+0x170 [xeno_nucleus])
 |  # func                  89	  1.428  __xnpod_schedule+0x14 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
 |  # [ 5284] 000000 257    90	  1.000  __xnpod_schedule+0x194 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
 |  # func                  91	  1.857  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
 |  # [ 5283] M88E6xx 90    93	  3.285  __xnpod_schedule+0x604 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
 |  # func                  96	  1.285  __ipipe_restore_head+0x10 (rt_sem_p_inner+0x170 [xeno_native])
 |  + end     0x80000000    98	  2.142  __ipipe_restore_head+0xd8 (rt_sem_p_inner+0x170 [xeno_native])
 |  + begin   0x80000001   100	  1.142  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
 |  + end     0x80000001   101	  1.000  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
 |  + func                 102	  0.857  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
 |  + end     0x90000000   103	 47.428  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0ca5c>)
 |  + begin   0x90000000   150	  0.857  vector_swi+0x3c (<b6f0d7fe>)
    + func                 151	  1.000  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
 |  + begin   0x80000001   152	  1.285  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
 |  + end     0x80000001   153	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
    + func                 154	  1.000  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)
 |  + begin   0x80000001   155	  1.000  ipipe_syscall_hook+0x9c (__ipipe_notify_syscall+0xc0)
 |  + end     0x80000001   156	  0.857  ipipe_syscall_hook+0x70 (__ipipe_notify_syscall+0xc0)
    + func                 157	  1.000  hisyscall_event+0x14 [xeno_nucleus] (ipipe_syscall_hook+0x90)
    + func                 158	  0.857  __rt_timer_inquire+0x14 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
    + func                 159	  0.857  rt_timer_inquire+0x10 [xeno_native] (__rt_timer_inquire+0x24 [xeno_native])
    + func                 160	  1.285  xnarch_tsc_to_ns+0x10 [xeno_nucleus] (rt_timer_inquire+0x38 [xeno_native])
 |  + begin   0x80000001   161	  1.285  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
 |  + end     0x80000001   162	  0.857  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
 |  + func                 163	  0.857  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
 |  + end     0x90000000   164	  3.428  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0d802>)
 |  + begin   0x90000000   167	  1.000  vector_swi+0x3c (<b6f0cb12>)
    + func                 168	  1.000  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
 |  + begin   0x80000001   169	  1.285  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
 |  + end     0x80000001   171	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
    + func                 172	  0.000  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)

Not sure anything there looks that big.  I wonder if the gpio bank is
just slow to generate the IRQ in the first place for some reason.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Mon, Nov 17, 2014 at 05:10:01PM -0500, Lennart Sorensen wrote:
> On Mon, Nov 17, 2014 at 10:54:58PM +0100, Gilles Chanteperdrix wrote:
> > On Mon, Nov 17, 2014 at 04:47:34PM -0500, Lennart Sorensen wrote:
> > > On Mon, Nov 17, 2014 at 09:27:54PM +0100, Gilles Chanteperdrix wrote:
> > > > On Mon, Nov 17, 2014 at 03:24:25PM -0500, Lennart Sorensen wrote:
> > > > > On Mon, Nov 17, 2014 at 09:14:35PM +0100, Gilles Chanteperdrix wrote:
> > > > > > Well, have you tried triggering an I-pipe tracer trace to see what
> > > > > > happens in the interval?
> > > > > 
> > > > > I have never used the tracer. I suppose I should learn how.
> > > > 
> > > > It is not very complicated. I have already been told on this list
> > > > that it was not well documented. I do not think so, but I let you
> > > > judge of that.
> > > > 
> > > > http://xenomai.org/2014/06/using-the-i-pipe-tracer/
> > > 
> > > So here is what I got triggering a couple of times on the IRQ.  Not
> > > entirely sure how to make sense of it, although there is one huge number.
> > > 
> > > back_trace_points:100
> > > enable:1
> > > frozen:I-pipe frozen back-tracing service on 3.12-1-am5726/ipipe release #2
> > > frozen:------------------------------------------------------------
> > > frozen:CPU: 0, Freeze: 2415647132 cycles, Trace Points: 100 (+10)
> > > frozen:Calibrated minimum trace-point overhead: 0.428 us
> > > frozen: +----- Hard IRQs ('|': locked)
> > > frozen: |+-- Xenomai
> > > frozen: ||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
> > > frozen: |||			  +---------- Delay flag ('+': > 1 us, '!': > 10 us)
> > > frozen: |||			  |	   +- NMI noise ('N')
> > > frozen: |||			  |	   |
> > > frozen:	  Type	  User Val.   Time    Delay  Function (Parent)
> > > frozen::    #func                -662	  0.857  arch_cpu_idle_enter+0x10 (cpu_startup_entry+0xb8)
> > > frozen::    #func                -661	  1.000  ledtrig_cpu+0x10 (arch_cpu_idle_enter+0x1c)
> > > frozen::    #func                -660	  1.000  led_trigger_event+0x10 (ledtrig_cpu+0x58)
> > > frozen::    #func                -659+   1.285  _raw_read_lock+0x10 (led_trigger_event+0x30)
> > > frozen::    #func                -658	  0.857  tick_check_broadcast_expired+0x10 (cpu_startup_entry+0x40)
> > > frozen::    #func                -657	  1.000  rcu_idle_enter+0x10 (cpu_startup_entry+0x58)
> > > frozen::    #func                -656	  0.857  ipipe_test_and_stall_root+0x10 (rcu_idle_enter+0x18)
> > > frozen::    #func                -655	  0.857  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
> > > frozen::|   #begin   0x80000001  -654+   1.428  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
> > > frozen::|   #end     0x80000001  -653	  1.000  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
> > > frozen::|   #begin   0x80000001  -652	  1.000  ipipe_test_and_stall_root+0x84 (rcu_idle_enter+0x18)
> > > frozen::|   #end     0x80000001  -651	  1.000  ipipe_test_and_stall_root+0x70 (rcu_idle_enter+0x18)
> > > frozen::    #func                -650	  1.000  rcu_eqs_enter_common.isra.47+0x14 (rcu_idle_enter+0x84)
> > > frozen::    #func                -649	  1.000  arch_cpu_idle+0x10 (cpu_startup_entry+0x5c)
> > > frozen::|   #begin   0x80000000  -648	  1.000  arch_cpu_idle+0xa4 (cpu_startup_entry+0x5c)
> > > frozen::|   +func                -647! 555.142 omap_default_idle+0x10 (arch_cpu_idle+0x90)      <-- What ever is
> > > that?  That looks huge.
> > 
> > As the name suggests, it means that the CPU remains idle for 500us.
> > You know, when the cpu load is not 100%, this is what the cpu is
> > doing the rest of the time, executing the wfi instruction to wait
> > for the next interrupt.
> > 
> > > frozen::|   +end     0x80000000   -92+   1.142 omap_default_idle+0x40 (arch_cpu_idle+0x90)
> >   (...)
> > > frozen::|  +*func                  -6	  0.857  gic_handle_irq+0x10 (__irq_svc+0x58)
> > > frozen::|  +*func                  -6	  1.000  irq_find_mapping+0x14 (gic_handle_irq+0x30)
> > > frozen::|  +*func                  -5	  0.857  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
> > > frozen::|  +*begin   0x00000043    -4	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
> > > frozen::|  +*func                  -3	  0.857  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
> > > frozen::|  +*func                  -2	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> > > frozen::|  +*func                  -1+   1.285  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> > > frozen:<|  +*func                   0	  1.142  gpio_irq_handler+0x14 (__ipipe_dispatch_irq+0x70)
> > > frozen: |  +*func                   1	  1.571  irq_to_desc+0x10 (gpio_irq_handler+0x38)
> > > frozen: |  +*func                   2	  1.000  irq_find_mapping+0x14 (gpio_irq_handler+0x190)
> > > frozen: |  +*begin   0x0000018e     3	  0.857  gpio_irq_handler+0x198 (__ipipe_dispatch_irq+0x70)
> > > frozen: |  +*func                   4	  0.857  __ipipe_dispatch_irq+0x14 (gpio_irq_handler+0x1a4)
> > > frozen: |  +*func                   5	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> > > frozen: |  +*func                   6	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> > > frozen: |  +*func                   7	  1.142  __ipipe_ack_level_irq+0x10 (__ipipe_dispatch_irq+0x70)
> > > frozen: |  +*func                   8	  0.857  gpio_mask_ack_irq+0x10 (__ipipe_ack_level_irq+0x30)
> > > frozen: |  +*func                   9	  3.428  __ipipe_spin_lock_irqsave+0x10 (gpio_mask_ack_irq+0x30)
> > > frozen: |  #*func                  13	  0.000
> > > __ipipe_spin_unlock_irqrestore+0x10 (gpio_mask_ack_irq+0x210)
> > 
> > 
> > So, the end of the trace is executing gpio_mask_ack_irq. Trace is
> > to short. It stops just when things were beginning to become
> > interesting. Please increase the number of trace points.
> 
> Good to know.  Will increase it.
> 
> I increases it to 100 and get this:
> 
> I-pipe frozen back-tracing service on 3.12-1-am5726/ipipe release #2
> ------------------------------------------------------------
> CPU: 0, Freeze: 2472048413 cycles, Trace Points: 100 (+100)
> Calibrated minimum trace-point overhead: 0.428 us
> 
>  +----- Hard IRQs ('|': locked)
>  |+-- Xenomai
>  ||+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
>  |||			  +---------- Delay flag ('+': > 1 us, '!': > 10 us)
>  |||			  |	   +- NMI noise ('N')
>  |||			  |	   |
> 	  Type	  User Val.   Time    Delay  Function (Parent)
> :    #func                -104	  0.857  internal_add_timer+0x10 (mod_timer+0x10c)
> :    #func                -103	  1.000  __internal_add_timer+0x10 (internal_add_timer+0x20)
> :    #func                -102	  0.857  __ipipe_spin_unlock_debug+0x10 (mod_timer+0x114)
> :    #func                -102	  1.000  _raw_spin_unlock_irqrestore+0x10 (mod_timer+0x120)
> :    #func                -101	  1.000  ipipe_unstall_root+0x10 (_raw_spin_unlock_irqrestore+0x38)
> :|   #begin   0x80000000  -100	  1.000  ipipe_unstall_root+0x90 (_raw_spin_unlock_irqrestore+0x38)
> :|   #func                 -99+   1.428  ipipe_root_only+0x14 (ipipe_unstall_root+0x24)
> :|   +end     0x80000000   -97	  1.000  ipipe_unstall_root+0x7c (_raw_spin_unlock_irqrestore+0x38)
> :    +func                 -96	  1.000  _raw_spin_lock_irq+0x10 (run_timer_softirq+0x1f4)
> :    +func                 -95	  1.000  ipipe_stall_root+0x10 (_raw_spin_lock_irq+0x1c)
> :    +func                 -94	  0.857  ipipe_root_only+0x14 (ipipe_stall_root+0x18)
> :|   +begin   0x80000001   -93+   1.285  ipipe_root_only+0xb8 (ipipe_stall_root+0x18)
> :|   +end     0x80000001   -92	  1.000  ipipe_root_only+0xa4 (ipipe_stall_root+0x18)
> :|   +begin   0x80000001   -91+   1.142  ipipe_stall_root+0x7c (_raw_spin_lock_irq+0x1c)
> :|   #end     0x80000001   -90+   1.142  ipipe_stall_root+0x6c (_raw_spin_lock_irq+0x1c)
> :    #func                 -89	  1.000  ipipe_unstall_root+0x10 (run_timer_softirq+0x1d0)
> :|   #begin   0x80000000   -88	  0.857  ipipe_unstall_root+0x90 (run_timer_softirq+0x1d0)
> :|   #func                 -87+   1.428  ipipe_root_only+0x14 (ipipe_unstall_root+0x24)
> :|   +end     0x80000000   -85+   1.142  ipipe_unstall_root+0x7c (run_timer_softirq+0x1d0)
> :    +func                 -84	  0.857  rcu_bh_qs+0x10 (__do_softirq+0x134)
> :    +func                 -83	  0.857  ipipe_stall_root+0x10 (__do_softirq+0x148)
> :    +func                 -83	  1.000  ipipe_root_only+0x14 (ipipe_stall_root+0x18)
> :|   +begin   0x80000001   -82+   1.285  ipipe_root_only+0xb8 (ipipe_stall_root+0x18)
> :|   +end     0x80000001   -80	  1.000  ipipe_root_only+0xa4 (ipipe_stall_root+0x18)
> :|   +begin   0x80000001   -79+   1.142  ipipe_stall_root+0x7c (__do_softirq+0x148)
> :|   #end     0x80000001   -78	  1.000  ipipe_stall_root+0x6c (__do_softirq+0x148)
> :    #func                 -77	  1.000  __local_bh_enable+0x10 (__do_softirq+0x1a8)
> :    #func                 -76	  0.857  ipipe_test_root+0x10 (__local_bh_enable+0x40)
> :|   #begin   0x80000001   -75+   1.142  ipipe_test_root+0x78 (__local_bh_enable+0x40)
> :|   #end     0x80000001   -74	  1.000  ipipe_test_root+0x64 (__local_bh_enable+0x40)
> :    #func                 -73	  0.857  ipipe_root_only+0x14 (__local_bh_enable+0x4c)
> :|   #begin   0x80000001   -72+   1.285  ipipe_root_only+0xb8 (__local_bh_enable+0x4c)
> :|   #end     0x80000001   -71	  1.000  ipipe_root_only+0xa4 (__local_bh_enable+0x4c)
> :    #func                 -70	  1.000  rcu_irq_exit+0x10 (irq_exit+0x84)
> :    #func                 -69	  0.857  ipipe_test_and_stall_root+0x10 (rcu_irq_exit+0x18)
> :    #func                 -68	  1.000  ipipe_root_only+0x14 (ipipe_test_and_stall_root+0x18)
> :|   #begin   0x80000001   -67+   1.285  ipipe_root_only+0xb8 (ipipe_test_and_stall_root+0x18)
> :|   #end     0x80000001   -66	  1.000  ipipe_root_only+0xa4 (ipipe_test_and_stall_root+0x18)
> :|   #begin   0x80000001   -65	  1.000  ipipe_test_and_stall_root+0x84 (rcu_irq_exit+0x18)
> :|   #end     0x80000001   -64	  1.000  ipipe_test_and_stall_root+0x70 (rcu_irq_exit+0x18)
> :    #func                 -63+   1.142  rcu_eqs_enter_common.isra.47+0x14 (rcu_irq_exit+0x84)
> :|   #begin   0x80000000   -62+   1.285  __ipipe_do_sync_stage+0x288 (__ipipe_do_sync_pipeline+0x140)
> :|   +end     0x0000001b   -60	  0.857  __ipipe_grab_irq+0x7c (gic_handle_irq+0x38)
> :|   +func                 -60	  0.857  __ipipe_exit_irq+0x10 (__ipipe_grab_irq+0x84)
> :|   +func                 -59+   1.142  __ipipe_check_root_interruptible+0x10 (__irq_svc+0x5c)
> :|   +func                 -58+   1.142  ipipe_test_root+0x10 (__ipipe_check_root_interruptible+0x60)
> :|   +func                 -56	  1.000  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_fast_svc_irq_exit+0x4)
> :|   +end     0x90000000   -55	  1.000  __ipipe_fast_svc_irq_exit+0x18 (omap_default_idle+0x44)
> :    +func                 -54	  1.000  ipipe_unstall_root+0x10 (arch_cpu_idle+0x94)
> :|   +begin   0x80000000   -53	  0.857  ipipe_unstall_root+0x90 (arch_cpu_idle+0x94)
> :|   +func                 -53+   1.571  ipipe_root_only+0x14 (ipipe_unstall_root+0x24)
> :|   +end     0x80000000   -51	  1.000  ipipe_unstall_root+0x7c (arch_cpu_idle+0x94)
> :    +func                 -50	  0.857  ipipe_test_root+0x10 (cpu_startup_entry+0x60)
> :|   +begin   0x80000001   -49+   1.142  ipipe_test_root+0x78 (cpu_startup_entry+0x60)
> :|   +end     0x80000001   -48+   1.142  ipipe_test_root+0x64 (cpu_startup_entry+0x60)
> :|   +begin   0x90000000   -47	  1.000  __irq_svc+0x44 (ipipe_test_root+0x68)
> :|   +func                 -46	  0.857  gic_handle_irq+0x10 (__irq_svc+0x58)
> :|   +func                 -45	  1.000  irq_find_mapping+0x14 (gic_handle_irq+0x30)
> :|   +func                 -44	  1.000  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
> :|   +begin   0x0000001b   -43	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
> :|   +func                 -42	  1.000  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
> :|   +func                 -41	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> :|   +func                 -40	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> :|   +func                 -39	  1.000  __ipipe_ack_hrtimer_irq+0x10 (__ipipe_dispatch_irq+0x70)
> :|   +func                 -38	  1.000  __ipipe_ack_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x60)
> :|   +func                 -37	  0.857  gic_hold_irq+0x10 (__ipipe_ack_fasteoi_irq+0x24)
> :|   +func                 -36+   1.142  __ipipe_spin_lock_irqsave+0x10 (gic_hold_irq+0x34)
> :|   #func                 -35+   1.285  __ipipe_spin_unlock_irqrestore+0x10 (gic_hold_irq+0x98)
> :|   +func                 -34	  1.000  arch_itimer_ack_virt+0x10 (__ipipe_ack_hrtimer_irq+0x70)
> :|   +func                 -33	  0.857  __ipipe_end_fasteoi_irq+0x10 (__ipipe_ack_hrtimer_irq+0x88)
> :|   +func                 -32	  1.000  gic_release_irq+0x10 (__ipipe_end_fasteoi_irq+0x2c)
> :|   +func                 -31+   1.142  __ipipe_spin_lock_irqsave+0x10 (gic_release_irq+0x34)
> :|   #func                 -30+   1.857  __ipipe_spin_unlock_irqrestore+0x10 (gic_release_irq+0x74)
> :|  # func                 -28+   1.285  xnintr_clock_handler+0x14 [xeno_nucleus] (__ipipe_dispatch_irq+0x270)
> :|  # func                 -27	  0.857  xntimer_tick_aperiodic+0x14 [xeno_nucleus] (xnintr_clock_handler+0x1e0 [xeno_nucleus])
> :|  # func                 -26	  0.857  xnthread_timeout_handler+0x10 [xeno_nucleus] (xntimer_tick_aperiodic+0x13c [xeno_nucleus])
> :|  # func                 -25+   1.142  xnpod_resume_thread+0x14 [xeno_nucleus] (xnthread_timeout_handler+0x34 [xeno_nucleus])
> :|  # [ 5285] MAC Poll 0   -24+   1.285  xnpod_resume_thread+0x124 [xeno_nucleus] (xnthread_timeout_handler+0x34 [xeno_nucleus])
> :|  # func                 -22	  0.857  xntimer_next_local_shot+0x10 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
> :|  # event   tick@16049   -22	  0.857  xntimer_next_local_shot+0xb4 [xeno_nucleus] (xntimer_tick_aperiodic+0x288 [xeno_nucleus])
> :|  # func                 -21+   1.142  ipipe_timer_set+0x10 (xntimer_next_local_shot+0xbc [xeno_nucleus])
> :|  # func                 -20+   1.285  arch_timer_set_next_event_virt+0x10 (ipipe_timer_set+0x7c)
> :|  # func                 -18+   1.285  __xnpod_schedule+0x14 [xeno_nucleus] (xnintr_clock_handler+0x408 [xeno_nucleus])
> :|  # [    0] -<?>-   -1   -17	  1.000  __xnpod_schedule+0x194 [xeno_nucleus] (xnintr_clock_handler+0x408 [xeno_nucleus])
> :|  # func                 -16	  1.000  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
> :|  # func                 -15	  0.857  omap4_mute_pic+0x10 (__xnpod_schedule+0x714 [xeno_nucleus])
> :|  # func                 -14+   1.285  gic_mute+0x10 (omap4_mute_pic+0x1c)
> :|  # func                 -13+   1.857  _get_gpio_irqbank_mask+0x10 (omap4_mute_pic+0x58)
> :|  # [ 5285] MAC Poll 0   -11+   1.571  __xnpod_schedule+0x604 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
> :|  # func                  -9	  1.000  __ipipe_restore_head+0x10 (xnpod_suspend_thread+0x1c4 [xeno_nucleus])
> :|  + end     0x80000000    -8	  1.000  __ipipe_restore_head+0xd8 (xnpod_suspend_thread+0x1c4 [xeno_nucleus])
> :|  + begin   0x90000000    -7	  1.000  __irq_svc+0x44 (__ipipe_restore_head+0xdc)
> :|  + func                  -6	  1.000  gic_handle_irq+0x10 (__irq_svc+0x58)
> :|  + func                  -5	  0.857  irq_find_mapping+0x14 (gic_handle_irq+0x30)
> :|  + func                  -5	  1.000  __ipipe_grab_irq+0x10 (gic_handle_irq+0x38)
> :|  + begin   0x00000043    -4	  1.000  __ipipe_grab_irq+0x50 (gic_handle_irq+0x38)
> :|  + func                  -3	  0.857  __ipipe_dispatch_irq+0x14 (__ipipe_grab_irq+0x74)
> :|  + func                  -2	  1.000  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
> :|  + func                  -1+   1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
> <|  + func                   0	  1.142  gpio_irq_handler+0x14 (__ipipe_dispatch_irq+0x70)
>  |  + func                   1	  1.571  irq_to_desc+0x10 (gpio_irq_handler+0x38)
>  |  + func                   2	  1.000  irq_find_mapping+0x14 (gpio_irq_handler+0x190)
>  |  + begin   0x0000018e     3	  0.857  gpio_irq_handler+0x198 (__ipipe_dispatch_irq+0x70)
>  |  + func                   4	  0.857  __ipipe_dispatch_irq+0x14 (gpio_irq_handler+0x1a4)
>  |  + func                   5	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xd4)
>  |  + func                   6	  1.142  irq_to_desc+0x10 (__ipipe_dispatch_irq+0xe4)
>  |  + func                   7	  1.000  __ipipe_ack_level_irq+0x10 (__ipipe_dispatch_irq+0x70)
>  |  + func                   8	  1.000  gpio_mask_ack_irq+0x10 (__ipipe_ack_level_irq+0x30)
>  |  + func                   9	  3.571  __ipipe_spin_lock_irqsave+0x10 (gpio_mask_ack_irq+0x30)
>  |  # func                  13	  1.714  __ipipe_spin_unlock_irqrestore+0x10 (gpio_mask_ack_irq+0x210)
>  |  + func                  15	  1.142  __ipipe_set_irq_pending+0x10 (__ipipe_dispatch_irq+0x490)
>  |  + end     0x0000018e    16	  1.428  gpio_irq_handler+0x1ac (__ipipe_dispatch_irq+0x70)
>  |  + func                  17	  0.857  gic_eoi_irq+0x10 (gpio_irq_handler+0x168)
>  |  + func                  18	  1.142  __ipipe_spin_lock_irqsave+0x10 (gic_eoi_irq+0x24)
>  |  # func                  19	  1.714  __ipipe_spin_unlock_irqrestore+0x10 (gic_eoi_irq+0x48)
>  |  + func                  21	  1.142  __ipipe_do_sync_stage+0x14 (__ipipe_dispatch_irq+0x3d4)
>  |  # func                  22	  1.428  xnintr_irq_handler+0x14 [xeno_nucleus] (__ipipe_do_sync_stage+0x1e8)
>  |  # func                  23	  1.000  rt_intr_handler+0x10 [xeno_native] (xnintr_irq_handler+0x11c [xeno_nucleus])
>  |  # func                  24	  1.285  xnsynch_flush+0x14 [xeno_nucleus] (rt_intr_handler+0x3c [xeno_native])
>  |  # func                  26	  1.428  xnpod_resume_thread+0x14 [xeno_nucleus] (xnsynch_flush+0x160 [xeno_nucleus])
>  |  # [ 5284] 000000 257    27	  2.142  xnpod_resume_thread+0x124 [xeno_nucleus] (xnsynch_flush+0x160 [xeno_nucleus])
>  |  # func                  29	  1.428  __xnpod_schedule+0x14 [xeno_nucleus] (xnintr_irq_handler+0x318 [xeno_nucleus])
>  |  # [ 5285] MAC Poll 0    31	  0.857  __xnpod_schedule+0x194 [xeno_nucleus] (xnintr_irq_handler+0x318 [xeno_nucleus])
>  |  # func                  32	  2.000  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
>  |  # [ 5284] 000000 257    34	  3.142  __xnpod_schedule+0x604 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
>  |  # func                  37	  1.142  __ipipe_restore_head+0x10 (__rt_intr_wait+0x210 [xeno_native])
>  |  + end     0x80000000    38	  1.714  __ipipe_restore_head+0xd8 (__rt_intr_wait+0x210 [xeno_native])
>  |  + begin   0x80000001    40	  1.428  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
>  |  + end     0x80000001    41	  0.857  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
>  |  + func                  42	  1.000  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
>  |  + end     0x90000000    43	  2.142  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0ba30>)
>  |  + begin   0x90000000    45	  1.000  vector_swi+0x3c (<b6f0cb12>)
>     + func                  46	  0.857  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
>  |  + begin   0x80000001    47	  1.428  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
>  |  + end     0x80000001    48	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
>     + func                  49	  0.857  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)
>  |  + begin   0x80000001    50	  1.000  ipipe_syscall_hook+0x9c (__ipipe_notify_syscall+0xc0)
>  |  + end     0x80000001    51	  1.142  ipipe_syscall_hook+0x70 (__ipipe_notify_syscall+0xc0)
>     + func                  52	  1.000  hisyscall_event+0x14 [xeno_nucleus] (ipipe_syscall_hook+0x90)
>     + func                  53	  1.000  __rt_sem_v+0x14 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
>     + func                  54	  1.428  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_sem_v+0x68 [xeno_native])
>     + func                  56	  1.000  rt_sem_v+0x14 [xeno_native] (__rt_sem_v+0x74 [xeno_native])
>  |  + begin   0x80000000    57	  1.857  rt_sem_v+0x20c [xeno_native] (__rt_sem_v+0x74 [xeno_native])
>  |  # func                  58	  1.285  xnsynch_wakeup_one_sleeper+0x14 [xeno_nucleus] (rt_sem_v+0x218 [xeno_native])
>  |  # func                  60	  1.428  xnpod_resume_thread+0x14 [xeno_nucleus] (xnsynch_wakeup_one_sleeper+0x158 [xeno_nucleus])
>  |  # [ 5283] M88E6xx 90    61	  1.285  xnpod_resume_thread+0x124 [xeno_nucleus] (xnsynch_wakeup_one_sleeper+0x158 [xeno_nucleus])
>  |  # func                  62	  1.428  __xnpod_schedule+0x14 [xeno_nucleus] (rt_sem_v+0x268 [xeno_native])
>  |  # [ 5284] 000000 257    64	  0.857  __xnpod_schedule+0x194 [xeno_nucleus] (rt_sem_v+0x268 [xeno_native])
>  |  # func                  65	  1.571  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
>  |  # func                  66	  1.000  __ipipe_restore_head+0x10 (rt_sem_v+0x168 [xeno_native])
>  |  + end     0x80000000    67	  1.142  __ipipe_restore_head+0xd8 (rt_sem_v+0x168 [xeno_native])
>  |  + begin   0x80000001    68	  1.142  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
>  |  + end     0x80000001    70	  0.857  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
>  |  + func                  70	  0.857  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
>  |  + end     0x90000000    71	  2.000  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0cb16>)
>  |  + begin   0x90000000    73	  1.000  vector_swi+0x3c (<b6f0ba2c>)
>     + func                  74	  0.857  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
>  |  + begin   0x80000001    75	  1.285  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
>  |  + end     0x80000001    76	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
>     + func                  77	  1.000  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)
>  |  + begin   0x80000001    78	  1.000  ipipe_syscall_hook+0x9c (__ipipe_notify_syscall+0xc0)
>  |  + end     0x80000001    79	  0.857  ipipe_syscall_hook+0x70 (__ipipe_notify_syscall+0xc0)
>     + func                  80	  1.000  hisyscall_event+0x14 [xeno_nucleus] (ipipe_syscall_hook+0x90)
>     + func                  81	  1.000  __rt_intr_wait+0x14 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
>  |  + begin   0x80000000    82	  1.142  __rt_intr_wait+0xc8 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
>  |  # func                  83	  1.000  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_intr_wait+0x19c [xeno_native])
>  |  # func                  84	  1.000  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_intr_wait+0x1ac [xeno_native])
>  |  # func                  85	  0.857  xnregistry_fetch+0x10 [xeno_nucleus] (__rt_intr_wait+0x2a8 [xeno_native])
>  |  # func                  86	  1.285  xnsynch_sleep_on+0x14 [xeno_nucleus] (__rt_intr_wait+0x30c [xeno_native])
>  |  # func                  87	  1.285  xnpod_suspend_thread+0x14 [xeno_nucleus] (xnsynch_sleep_on+0x170 [xeno_nucleus])
>  |  # func                  89	  1.428  __xnpod_schedule+0x14 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
>  |  # [ 5284] 000000 257    90	  1.000  __xnpod_schedule+0x194 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
>  |  # func                  91	  1.857  xnsched_pick_next+0x10 [xeno_nucleus] (__xnpod_schedule+0x328 [xeno_nucleus])
>  |  # [ 5283] M88E6xx 90    93	  3.285  __xnpod_schedule+0x604 [xeno_nucleus] (xnpod_suspend_thread+0x494 [xeno_nucleus])
>  |  # func                  96	  1.285  __ipipe_restore_head+0x10 (rt_sem_p_inner+0x170 [xeno_native])
>  |  + end     0x80000000    98	  2.142  __ipipe_restore_head+0xd8 (rt_sem_p_inner+0x170 [xeno_native])
>  |  + begin   0x80000001   100	  1.142  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
>  |  + end     0x80000001   101	  1.000  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
>  |  + func                 102	  0.857  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
>  |  + end     0x90000000   103	 47.428  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0ca5c>)
>  |  + begin   0x90000000   150	  0.857  vector_swi+0x3c (<b6f0d7fe>)
>     + func                 151	  1.000  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
>  |  + begin   0x80000001   152	  1.285  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
>  |  + end     0x80000001   153	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
>     + func                 154	  1.000  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)
>  |  + begin   0x80000001   155	  1.000  ipipe_syscall_hook+0x9c (__ipipe_notify_syscall+0xc0)
>  |  + end     0x80000001   156	  0.857  ipipe_syscall_hook+0x70 (__ipipe_notify_syscall+0xc0)
>     + func                 157	  1.000  hisyscall_event+0x14 [xeno_nucleus] (ipipe_syscall_hook+0x90)
>     + func                 158	  0.857  __rt_timer_inquire+0x14 [xeno_native] (hisyscall_event+0x1a0 [xeno_nucleus])
>     + func                 159	  0.857  rt_timer_inquire+0x10 [xeno_native] (__rt_timer_inquire+0x24 [xeno_native])
>     + func                 160	  1.285  xnarch_tsc_to_ns+0x10 [xeno_nucleus] (rt_timer_inquire+0x38 [xeno_native])
>  |  + begin   0x80000001   161	  1.285  __ipipe_notify_syscall+0x208 (pipeline_syscall+0x8)
>  |  + end     0x80000001   162	  0.857  __ipipe_notify_syscall+0x250 (pipeline_syscall+0x8)
>  |  + func                 163	  0.857  __ipipe_bugon_irqs_enabled+0x10 (__ipipe_ret_to_user_irqs_disabled+0x4)
>  |  + end     0x90000000   164	  3.428  __ipipe_ret_to_user_irqs_disabled+0x18 (<b6f0d802>)
>  |  + begin   0x90000000   167	  1.000  vector_swi+0x3c (<b6f0cb12>)
>     + func                 168	  1.000  __ipipe_notify_syscall+0x14 (pipeline_syscall+0x8)
>  |  + begin   0x80000001   169	  1.285  __ipipe_notify_syscall+0x2d0 (pipeline_syscall+0x8)
>  |  + end     0x80000001   171	  0.857  __ipipe_notify_syscall+0x1fc (pipeline_syscall+0x8)
>     + func                 172	  0.000  ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xc0)
> 
> Not sure anything there looks that big.  I wonder if the gpio bank is
> just slow to generate the IRQ in the first place for some reason.

No, I do not see anything wrong either. One thing that could delay
gpio irq delivery is PIC muting, if it has a bug with this SOC, so I
strongly suggest (once again) that you comment out PIC muting as
long as you have issues. Anyway, I do not think that is the case
here.

If the latency is not always off, you should trigger a trace only
when you detect that the latency is to large.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Mon, Nov 17, 2014 at 11:15:42PM +0100, Gilles Chanteperdrix wrote:
> On Mon, Nov 17, 2014 at 05:10:01PM -0500, Lennart Sorensen wrote:
> > Not sure anything there looks that big.  I wonder if the gpio bank is
> > just slow to generate the IRQ in the first place for some reason.

And yes it was.

> No, I do not see anything wrong either. One thing that could delay
> gpio irq delivery is PIC muting, if it has a bug with this SOC, so I
> strongly suggest (once again) that you comment out PIC muting as
> long as you have issues. Anyway, I do not think that is the case
> here.
> 
> If the latency is not always off, you should trigger a trace only
> when you detect that the latency is to large.

OK, found the problem.  The GPIO bank is by default (in the kernel,
not hardware) configured for 'SmartIdle' which apparently means it goes
to sleep and first has to wake up, power everything up, start the clock,
then measure the state of the pin for a couple of clocks before generating
an IRQ.  Turning off idle support entirely on the GPIO bank makes it
consistently about 30us response time, so that is great.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 10:24:22AM -0500, Lennart Sorensen wrote:
> On Mon, Nov 17, 2014 at 11:15:42PM +0100, Gilles Chanteperdrix wrote:
> > On Mon, Nov 17, 2014 at 05:10:01PM -0500, Lennart Sorensen wrote:
> > > Not sure anything there looks that big.  I wonder if the gpio bank is
> > > just slow to generate the IRQ in the first place for some reason.
> 
> And yes it was.
> 
> > No, I do not see anything wrong either. One thing that could delay
> > gpio irq delivery is PIC muting, if it has a bug with this SOC, so I
> > strongly suggest (once again) that you comment out PIC muting as
> > long as you have issues. Anyway, I do not think that is the case
> > here.
> > 
> > If the latency is not always off, you should trigger a trace only
> > when you detect that the latency is to large.
> 
> OK, found the problem.  The GPIO bank is by default (in the kernel,
> not hardware) configured for 'SmartIdle' which apparently means it goes
> to sleep and first has to wake up, power everything up, start the clock,
> then measure the state of the pin for a couple of clocks before generating
> an IRQ.  Turning off idle support entirely on the GPIO bank makes it
> consistently about 30us response time, so that is great.

Ok, there is already code in the I-pipe for turning off smartidle
for other peripherals (like the hardware timer, the omap specific
one used on omap3, and SMP omap4 and 5 when in UP mode, not the
cortex a9 global timer), so, any patch to toggle this bit with 
if (IS_ENABLED(IPIPE))
will be accepted.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 04:26:49PM +0100, Gilles Chanteperdrix wrote:
> Ok, there is already code in the I-pipe for turning off smartidle
> for other peripherals (like the hardware timer, the omap specific
> one used on omap3, and SMP omap4 and 5 when in UP mode, not the
> cortex a9 global timer), so, any patch to toggle this bit with 
> if (IS_ENABLED(IPIPE))
> will be accepted.

I am just adding 'ti,no-idle' to gpio7 in the dtb.  That appears to
be right.  Building it now to test it.

The handling is of in omap-hwmod.c, not in gpio-omap.c so not sure how
to make ipipe know that a given gpio bank is used for irq and should
not idle.  At least not in a clean manner.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 01:48:43PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 04:26:49PM +0100, Gilles Chanteperdrix wrote:
> > Ok, there is already code in the I-pipe for turning off smartidle
> > for other peripherals (like the hardware timer, the omap specific
> > one used on omap3, and SMP omap4 and 5 when in UP mode, not the
> > cortex a9 global timer), so, any patch to toggle this bit with 
> > if (IS_ENABLED(IPIPE))
> > will be accepted.
> 
> I am just adding 'ti,no-idle' to gpio7 in the dtb.  That appears to
> be right.  Building it now to test it.
> 
> The handling is of in omap-hwmod.c, not in gpio-omap.c so not sure how
> to make ipipe know that a given gpio bank is used for irq and should
> not idle.  At least not in a clean manner.

I would take the simple approach: disable the smartidle in the probe
function for all GPIO banks if IS_ENABLED(CONFIG_IPIPE)

Otherwise, the enable_irqdesc/disable_irqdesc functions already
keep track of which bank has real-time irq handlers registered, and
it is already conditionally compiled only if CONFIG_IPIPE is
enabled. So, you can add your code there.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 07:51:31PM +0100, Gilles Chanteperdrix wrote:
> I would take the simple approach: disable the smartidle in the probe
> function for all GPIO banks if IS_ENABLED(CONFIG_IPIPE)
> 
> Otherwise, the enable_irqdesc/disable_irqdesc functions already
> keep track of which bank has real-time irq handlers registered, and
> it is already conditionally compiled only if CONFIG_IPIPE is
> enabled. So, you can add your code there.

I will consider that after doing my other test.  For me adding one flag
to the dtb for our board seems less invasive, but for ipipe overall it
would be better to make ipipe turn of smartidle on the IRQ supporting
gpio banks.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 01:56:57PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 07:51:31PM +0100, Gilles Chanteperdrix wrote:
> > I would take the simple approach: disable the smartidle in the probe
> > function for all GPIO banks if IS_ENABLED(CONFIG_IPIPE)
> > 
> > Otherwise, the enable_irqdesc/disable_irqdesc functions already
> > keep track of which bank has real-time irq handlers registered, and
> > it is already conditionally compiled only if CONFIG_IPIPE is
> > enabled. So, you can add your code there.
> 
> I will consider that after doing my other test.  For me adding one flag
> to the dtb for our board seems less invasive, but for ipipe overall it
> would be better to make ipipe turn of smartidle on the IRQ supporting
> gpio banks.

RT IRQs only, we do not care about NRT IRQS, they can depend on the
dts parameter. Anyway, if you tell me where the code you are talking
about can be found, I can propose a patch that you test, and merge
it if it works for you.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 01:48:43PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 04:26:49PM +0100, Gilles Chanteperdrix wrote:
> > Ok, there is already code in the I-pipe for turning off smartidle
> > for other peripherals (like the hardware timer, the omap specific
> > one used on omap3, and SMP omap4 and 5 when in UP mode, not the
> > cortex a9 global timer), so, any patch to toggle this bit with 
> > if (IS_ENABLED(IPIPE))
> > will be accepted.
> 
> I am just adding 'ti,no-idle' to gpio7 in the dtb.  That appears to
> be right.  Building it now to test it.
> 
> The handling is of in omap-hwmod.c, not in gpio-omap.c so not sure how
> to make ipipe know that a given gpio bank is used for irq and should
> not idle.  At least not in a clean manner.

I am afraid this parameter can not be found in mainline kernel 3.16.
So, it must be a local addition of the kernel you use.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 08:00:14PM +0100, Gilles Chanteperdrix wrote:
> On Tue, Nov 18, 2014 at 01:56:57PM -0500, Lennart Sorensen wrote:
> > On Tue, Nov 18, 2014 at 07:51:31PM +0100, Gilles Chanteperdrix wrote:
> > > I would take the simple approach: disable the smartidle in the probe
> > > function for all GPIO banks if IS_ENABLED(CONFIG_IPIPE)
> > > 
> > > Otherwise, the enable_irqdesc/disable_irqdesc functions already
> > > keep track of which bank has real-time irq handlers registered, and
> > > it is already conditionally compiled only if CONFIG_IPIPE is
> > > enabled. So, you can add your code there.
> > 
> > I will consider that after doing my other test.  For me adding one flag
> > to the dtb for our board seems less invasive, but for ipipe overall it
> > would be better to make ipipe turn of smartidle on the IRQ supporting
> > gpio banks.
> 
> RT IRQs only, we do not care about NRT IRQS, they can depend on the
> dts parameter. Anyway, if you tell me where the code you are talking
> about can be found, I can propose a patch that you test, and merge
> it if it works for you.

Hmm, ti,no-idle causes a gpio bank startup failure, so that doesn't work.

The code setting it to idle is in arch/arm/mach-omap2/omap_hwmod.c:

static void _enable_sysc(struct omap_hwmod *oh)
{
        u8 idlemode, sf;
        u32 v;
        bool clkdm_act;
        struct clockdomain *clkdm;

        if (!oh->class->sysc)
                return;

        /*
         * Wait until reset has completed, this is needed as the IP
         * block is reset automatically by hardware in some cases
         * (off-mode for example), and the drivers require the
         * IP to be ready when they access it
         */
        if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
                _enable_optional_clocks(oh);
        _wait_softreset_complete(oh);
        if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
                _disable_optional_clocks(oh);

        v = oh->_sysc_cache;
        sf = oh->class->sysc->sysc_flags;

        clkdm = _get_clkdm(oh);
        if (sf & SYSC_HAS_SIDLEMODE) {
                if (oh->flags & HWMOD_SWSUP_SIDLE ||
                    oh->flags & HWMOD_SWSUP_SIDLE_ACT) {
                        idlemode = HWMOD_IDLEMODE_NO;
                } else {
                        if (sf & SYSC_HAS_ENAWAKEUP)
                                _enable_wakeup(oh, &v);
                        if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
                                idlemode = HWMOD_IDLEMODE_SMART_WKUP; <- this one
                        else
                                idlemode = HWMOD_IDLEMODE_SMART; <- or this one
                }

                /*
                 * This is special handling for some IPs like
                 * 32k sync timer. Force them to idle!
                 */
                clkdm_act = (clkdm && clkdm->flags & CLKDM_ACTIVE_WITH_MPU);
                if (clkdm_act && !(oh->class->sysc->idlemodes &
                                   (SIDLE_SMART | SIDLE_SMART_WKUP)))
                        idlemode = HWMOD_IDLEMODE_FORCE;

                _set_slave_idlemode(oh, idlemode, &v);
        }

The hwmod for the gpio bank in question is in
arch/arm/mach-omap2/omap_hwmod_7xx_data.c:

/*
 * 'gpio' class
 *
 */

static struct omap_hwmod_class_sysconfig dra7xx_gpio_sysc = {
        .rev_offs       = 0x0000,
        .sysc_offs      = 0x0010,
        .syss_offs      = 0x0114,
        .sysc_flags     = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
                           SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
                           SYSS_HAS_RESET_STATUS),
        .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
                           SIDLE_SMART_WKUP),
        .sysc_fields    = &omap_hwmod_sysc_type1,
};

and later

/* gpio7 */

static struct omap_hwmod dra7xx_gpio7_hwmod = {
        .name           = "gpio7",
        .class          = &dra7xx_gpio_hwmod_class,
        .clkdm_name     = "l4per_clkdm",
        .flags          = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
        .prcm = {
                .omap4 = {
                        .clkctrl_offs = DRA7XX_CM_L4PER_GPIO7_CLKCTRL_OFFSET,
                        .context_offs = DRA7XX_RM_L4PER_GPIO7_CONTEXT_OFFSET,
                        .modulemode   = MODULEMODE_HWCTRL,
                },
        },
        .dev_attr       = &gpio_dev_attr,
};

Code can be found here:

http://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/ti-linux-3.12.y

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 08:14:48PM +0100, Gilles Chanteperdrix wrote:
> On Tue, Nov 18, 2014 at 01:48:43PM -0500, Lennart Sorensen wrote:
> > On Tue, Nov 18, 2014 at 04:26:49PM +0100, Gilles Chanteperdrix wrote:
> > > Ok, there is already code in the I-pipe for turning off smartidle
> > > for other peripherals (like the hardware timer, the omap specific
> > > one used on omap3, and SMP omap4 and 5 when in UP mode, not the
> > > cortex a9 global timer), so, any patch to toggle this bit with 
> > > if (IS_ENABLED(IPIPE))
> > > will be accepted.
> > 
> > I am just adding 'ti,no-idle' to gpio7 in the dtb.  That appears to
> > be right.  Building it now to test it.
> > 
> > The handling is of in omap-hwmod.c, not in gpio-omap.c so not sure how
> > to make ipipe know that a given gpio bank is used for irq and should
> > not idle.  At least not in a clean manner.
> 
> I am afraid this parameter can not be found in mainline kernel 3.16.
> So, it must be a local addition of the kernel you use.

Yeah I am using the ti-linux tree since they are not done merging yet.

Not that it worked anyhow.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 02:24:37PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 08:00:14PM +0100, Gilles Chanteperdrix wrote:
> > On Tue, Nov 18, 2014 at 01:56:57PM -0500, Lennart Sorensen wrote:
> > > On Tue, Nov 18, 2014 at 07:51:31PM +0100, Gilles Chanteperdrix wrote:
> > > > I would take the simple approach: disable the smartidle in the probe
> > > > function for all GPIO banks if IS_ENABLED(CONFIG_IPIPE)
> > > > 
> > > > Otherwise, the enable_irqdesc/disable_irqdesc functions already
> > > > keep track of which bank has real-time irq handlers registered, and
> > > > it is already conditionally compiled only if CONFIG_IPIPE is
> > > > enabled. So, you can add your code there.
> > > 
> > > I will consider that after doing my other test.  For me adding one flag
> > > to the dtb for our board seems less invasive, but for ipipe overall it
> > > would be better to make ipipe turn of smartidle on the IRQ supporting
> > > gpio banks.
> > 
> > RT IRQs only, we do not care about NRT IRQS, they can depend on the
> > dts parameter. Anyway, if you tell me where the code you are talking
> > about can be found, I can propose a patch that you test, and merge
> > it if it works for you.
> 
> Hmm, ti,no-idle causes a gpio bank startup failure, so that doesn't work.
> 
> The code setting it to idle is in arch/arm/mach-omap2/omap_hwmod.c:
> 
> static void _enable_sysc(struct omap_hwmod *oh)
> {
>         u8 idlemode, sf;
>         u32 v;
>         bool clkdm_act;
>         struct clockdomain *clkdm;
> 
>         if (!oh->class->sysc)
>                 return;
> 
>         /*
>          * Wait until reset has completed, this is needed as the IP
>          * block is reset automatically by hardware in some cases
>          * (off-mode for example), and the drivers require the
>          * IP to be ready when they access it
>          */
>         if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
>                 _enable_optional_clocks(oh);
>         _wait_softreset_complete(oh);
>         if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
>                 _disable_optional_clocks(oh);
> 
>         v = oh->_sysc_cache;
>         sf = oh->class->sysc->sysc_flags;
> 
>         clkdm = _get_clkdm(oh);
>         if (sf & SYSC_HAS_SIDLEMODE) {
>                 if (oh->flags & HWMOD_SWSUP_SIDLE ||
>                     oh->flags & HWMOD_SWSUP_SIDLE_ACT) {
>                         idlemode = HWMOD_IDLEMODE_NO;
>                 } else {
>                         if (sf & SYSC_HAS_ENAWAKEUP)
>                                 _enable_wakeup(oh, &v);
>                         if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
>                                 idlemode = HWMOD_IDLEMODE_SMART_WKUP; <- this one
>                         else
>                                 idlemode = HWMOD_IDLEMODE_SMART; <- or this one
>                 }
> 
>                 /*
>                  * This is special handling for some IPs like
>                  * 32k sync timer. Force them to idle!
>                  */
>                 clkdm_act = (clkdm && clkdm->flags & CLKDM_ACTIVE_WITH_MPU);
>                 if (clkdm_act && !(oh->class->sysc->idlemodes &
>                                    (SIDLE_SMART | SIDLE_SMART_WKUP)))
>                         idlemode = HWMOD_IDLEMODE_FORCE;
> 
>                 _set_slave_idlemode(oh, idlemode, &v);
>         }
> 
> The hwmod for the gpio bank in question is in
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c:
> 
> /*
>  * 'gpio' class
>  *
>  */
> 
> static struct omap_hwmod_class_sysconfig dra7xx_gpio_sysc = {
>         .rev_offs       = 0x0000,
>         .sysc_offs      = 0x0010,
>         .syss_offs      = 0x0114,
>         .sysc_flags     = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
>                            SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
>                            SYSS_HAS_RESET_STATUS),
>         .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>                            SIDLE_SMART_WKUP),
>         .sysc_fields    = &omap_hwmod_sysc_type1,
> };

What if you remove SYSC_HAS_SIDLEMODE here ?

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 02:25:30PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 08:14:48PM +0100, Gilles Chanteperdrix wrote:
> > On Tue, Nov 18, 2014 at 01:48:43PM -0500, Lennart Sorensen wrote:
> > > On Tue, Nov 18, 2014 at 04:26:49PM +0100, Gilles Chanteperdrix wrote:
> > > > Ok, there is already code in the I-pipe for turning off smartidle
> > > > for other peripherals (like the hardware timer, the omap specific
> > > > one used on omap3, and SMP omap4 and 5 when in UP mode, not the
> > > > cortex a9 global timer), so, any patch to toggle this bit with 
> > > > if (IS_ENABLED(IPIPE))
> > > > will be accepted.
> > > 
> > > I am just adding 'ti,no-idle' to gpio7 in the dtb.  That appears to
> > > be right.  Building it now to test it.
> > > 
> > > The handling is of in omap-hwmod.c, not in gpio-omap.c so not sure how
> > > to make ipipe know that a given gpio bank is used for irq and should
> > > not idle.  At least not in a clean manner.
> > 
> > I am afraid this parameter can not be found in mainline kernel 3.16.
> > So, it must be a local addition of the kernel you use.
> 
> Yeah I am using the ti-linux tree since they are not done merging yet.
> 
> Not that it worked anyhow.

Just something to inform you. The status of Xenomai patches for
vendor forks are:
- imx6 using 3.0 fork, somewhat maintained: inexplicable hangups,
and a situation where it is hard not to suspect the young age of the
port in the kernel used;
- beaglebone using 3.8 fork: patch submitted, no feedback, no
further submission; considered bitroting now
- raspberry: same as beaglebone
- zynq: two patches submitted, one for 3.5 and one for 3.8, but
otherwise same as beaglebone and raspberry.

In my experience, when people choose a kernel version for an
industrial project, they tend to stick to that version for the
duration of the project, or even for all the projects they do with
the same processors. The result is that if they need an I-pipe patch
for their project, they need it for one kernel version, so their
contribution is of the "drop and go" kind. Simply because when this
project is finished, another starts, maybe using a newer processor,
and so they never get the time to upgrade the patch to a kernel
version they do not need.

So, it is much better to contribute I-pipe patches to the mainline
kernel I-pipe branch. Simply because, when I merge them, I
compile-test them for every following supported mainline kernel
release. So, even if some kernel change broke the patch without
breaking compilation (this happens, and not even rarely), you have
something from which you can start on a current release.

But my vendor fork supports hardware X or Y! Well, then port the
driver for hardware X or Y to the mainline kernel, this will not
take monthes to do (assuuming you will not try and get the drivers
merged into mainline, because THAT would cost you a lot of time,
there is a reason why vendors keep them in forks and do not try and
merge them).

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 08:28:46PM +0100, Gilles Chanteperdrix wrote:
> On Tue, Nov 18, 2014 at 02:24:37PM -0500, Lennart Sorensen wrote:
> > On Tue, Nov 18, 2014 at 08:00:14PM +0100, Gilles Chanteperdrix wrote:
> > > On Tue, Nov 18, 2014 at 01:56:57PM -0500, Lennart Sorensen wrote:
> > > > On Tue, Nov 18, 2014 at 07:51:31PM +0100, Gilles Chanteperdrix wrote:
> > > > > I would take the simple approach: disable the smartidle in the probe
> > > > > function for all GPIO banks if IS_ENABLED(CONFIG_IPIPE)
> > > > > 
> > > > > Otherwise, the enable_irqdesc/disable_irqdesc functions already
> > > > > keep track of which bank has real-time irq handlers registered, and
> > > > > it is already conditionally compiled only if CONFIG_IPIPE is
> > > > > enabled. So, you can add your code there.
> > > > 
> > > > I will consider that after doing my other test.  For me adding one flag
> > > > to the dtb for our board seems less invasive, but for ipipe overall it
> > > > would be better to make ipipe turn of smartidle on the IRQ supporting
> > > > gpio banks.
> > > 
> > > RT IRQs only, we do not care about NRT IRQS, they can depend on the
> > > dts parameter. Anyway, if you tell me where the code you are talking
> > > about can be found, I can propose a patch that you test, and merge
> > > it if it works for you.
> > 
> > Hmm, ti,no-idle causes a gpio bank startup failure, so that doesn't work.
> > 
> > The code setting it to idle is in arch/arm/mach-omap2/omap_hwmod.c:
> > 
> > static void _enable_sysc(struct omap_hwmod *oh)
> > {
> >         u8 idlemode, sf;
> >         u32 v;
> >         bool clkdm_act;
> >         struct clockdomain *clkdm;
> > 
> >         if (!oh->class->sysc)
> >                 return;
> > 
> >         /*
> >          * Wait until reset has completed, this is needed as the IP
> >          * block is reset automatically by hardware in some cases
> >          * (off-mode for example), and the drivers require the
> >          * IP to be ready when they access it
> >          */
> >         if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
> >                 _enable_optional_clocks(oh);
> >         _wait_softreset_complete(oh);
> >         if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
> >                 _disable_optional_clocks(oh);
> > 
> >         v = oh->_sysc_cache;
> >         sf = oh->class->sysc->sysc_flags;
> > 
> >         clkdm = _get_clkdm(oh);
> >         if (sf & SYSC_HAS_SIDLEMODE) {
> >                 if (oh->flags & HWMOD_SWSUP_SIDLE ||
> >                     oh->flags & HWMOD_SWSUP_SIDLE_ACT) {
> >                         idlemode = HWMOD_IDLEMODE_NO;
> >                 } else {
> >                         if (sf & SYSC_HAS_ENAWAKEUP)
> >                                 _enable_wakeup(oh, &v);
> >                         if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
> >                                 idlemode = HWMOD_IDLEMODE_SMART_WKUP; <- this one
> >                         else
> >                                 idlemode = HWMOD_IDLEMODE_SMART; <- or this one
> >                 }
> > 
> >                 /*
> >                  * This is special handling for some IPs like
> >                  * 32k sync timer. Force them to idle!
> >                  */
> >                 clkdm_act = (clkdm && clkdm->flags & CLKDM_ACTIVE_WITH_MPU);
> >                 if (clkdm_act && !(oh->class->sysc->idlemodes &
> >                                    (SIDLE_SMART | SIDLE_SMART_WKUP)))
> >                         idlemode = HWMOD_IDLEMODE_FORCE;
> > 
> >                 _set_slave_idlemode(oh, idlemode, &v);
> >         }
> > 
> > The hwmod for the gpio bank in question is in
> > arch/arm/mach-omap2/omap_hwmod_7xx_data.c:
> > 
> > /*
> >  * 'gpio' class
> >  *
> >  */
> > 
> > static struct omap_hwmod_class_sysconfig dra7xx_gpio_sysc = {
> >         .rev_offs       = 0x0000,
> >         .sysc_offs      = 0x0010,
> >         .syss_offs      = 0x0114,
> >         .sysc_flags     = (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
> >                            SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
> >                            SYSS_HAS_RESET_STATUS),
> >         .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> >                            SIDLE_SMART_WKUP),
> >         .sysc_fields    = &omap_hwmod_sysc_type1,
> > };
> 
> What if you remove SYSC_HAS_SIDLEMODE here ?

Another thing, what if you remove PM_RUNTIME in the kernel
configuration completely? On my omap3 and omap4 boards, this results
in some stupid warnings at boot time, but the system runs just fine.
And maybe this bypasses all that hwmod awful stuff.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 09:28:33PM +0100, Gilles Chanteperdrix wrote:
> On Tue, Nov 18, 2014 at 08:28:46PM +0100, Gilles Chanteperdrix wrote:
> > What if you remove SYSC_HAS_SIDLEMODE here ?

I suspect that would work, but I was trying not to mess with the hwmod
if I could.  I am trying the ti,no-idle again since I screwed up the
test and it might actually work.

> Another thing, what if you remove PM_RUNTIME in the kernel
> configuration completely? On my omap3 and omap4 boards, this results
> in some stupid warnings at boot time, but the system runs just fine.
> And maybe this bypasses all that hwmod awful stuff.

TI is so sloppy that doing that causes a ton of compile errors.  Half the
power management code is wrapped in CONFIG_PM and the other half is not.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 03:53:03PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 09:28:33PM +0100, Gilles Chanteperdrix wrote:
> > On Tue, Nov 18, 2014 at 08:28:46PM +0100, Gilles Chanteperdrix wrote:
> > > What if you remove SYSC_HAS_SIDLEMODE here ?
> 
> I suspect that would work, but I was trying not to mess with the hwmod
> if I could.  I am trying the ti,no-idle again since I screwed up the
> test and it might actually work.
> 
> > Another thing, what if you remove PM_RUNTIME in the kernel
> > configuration completely? On my omap3 and omap4 boards, this results
> > in some stupid warnings at boot time, but the system runs just fine.
> > And maybe this bypasses all that hwmod awful stuff.
> 
> TI is so sloppy that doing that causes a ton of compile errors.  Half the
> power management code is wrapped in CONFIG_PM and the other half is not.

You are right. My configurations have PM_RUNTIME enabled both on
OMAP3 and OMAP4. I am almost sure I used to turn it off. But it may
be a while since I tested it.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 09:56:24PM +0100, Gilles Chanteperdrix wrote:
> On Tue, Nov 18, 2014 at 03:53:03PM -0500, Lennart Sorensen wrote:
> > On Tue, Nov 18, 2014 at 09:28:33PM +0100, Gilles Chanteperdrix wrote:
> > > On Tue, Nov 18, 2014 at 08:28:46PM +0100, Gilles Chanteperdrix wrote:
> > > > What if you remove SYSC_HAS_SIDLEMODE here ?
> > 
> > I suspect that would work, but I was trying not to mess with the hwmod
> > if I could.  I am trying the ti,no-idle again since I screwed up the
> > test and it might actually work.
> > 
> > > Another thing, what if you remove PM_RUNTIME in the kernel
> > > configuration completely? On my omap3 and omap4 boards, this results
> > > in some stupid warnings at boot time, but the system runs just fine.
> > > And maybe this bypasses all that hwmod awful stuff.
> > 
> > TI is so sloppy that doing that causes a ton of compile errors. 

It is not just TI. I believe all vendor forks have the same issue:
they are not written by people well versed into paying attention to
the kind of issue you have to pay attention to with Linux. Once
their patches get reviewed, of course they improve. But this takes a
lot of time, and for some drivers, they will not even make the
effort.

That being said, the last two vendor forks I used are for TI DM8148,
and Xilinx Zynq, and I have to admit that the TI DM8148 fork  code
is much much worse than the Xilinx one.

> Half the
> > power management code is wrapped in CONFIG_PM and the other half is not.
> 
> You are right. My configurations have PM_RUNTIME enabled both on
> OMAP3 and OMAP4. I am almost sure I used to turn it off. But it may
> be a while since I tested it.

Ok, it seems the TI mainline maintainers are less sloppy, the kernel
compiles and boot on both platforms. Less sloppy only because on my
OMAP3 board, the USB controller does not get initialized.

Anyway, this is not a good solution, this is clearly something that
nobody tests, thre is no reason to expect it what we would expect to
dot. 
> 
> -- 
> 					    Gilles.
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 10:17:13PM +0100, Gilles Chanteperdrix wrote:
> It is not just TI. I believe all vendor forks have the same issue:
> they are not written by people well versed into paying attention to
> the kind of issue you have to pay attention to with Linux. Once
> their patches get reviewed, of course they improve. But this takes a
> lot of time, and for some drivers, they will not even make the
> effort.

Certainly true.

> That being said, the last two vendor forks I used are for TI DM8148,
> and Xilinx Zynq, and I have to admit that the TI DM8148 fork  code
> is much much worse than the Xilinx one.
> 
> Ok, it seems the TI mainline maintainers are less sloppy, the kernel
> compiles and boot on both platforms. Less sloppy only because on my
> OMAP3 board, the USB controller does not get initialized.

TI seems to be on a 'Get it mainlined' kick lately, so perhaps they are
being more careful as a result.

> Anyway, this is not a good solution, this is clearly something that
> nobody tests, thre is no reason to expect it what we would expect to
> dot. 

I see this 'hack' in the omap timer code:

+#ifdef CONFIG_IPIPE
+       if (ipipe) {
+               u32 l;
+
+               l = __raw_readl(timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+               l = (0x3 << 8) | (l & (1 << 5)) | (0x1 << 3) | (1 << 2);
+               __raw_writel(l, timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+       }
+#endif

Sure would be nice if someone had actually defined what those bits are,
although it appears to be setting wakeup on, and idle mode to 'no idle',
and I didn't look up the 5 and 8 bits yet.

I was hoping to do something a lot cleaner than that.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 08:46:54PM +0100, Gilles Chanteperdrix wrote:
> Just something to inform you. The status of Xenomai patches for
> vendor forks are:
> - imx6 using 3.0 fork, somewhat maintained: inexplicable hangups,
> and a situation where it is hard not to suspect the young age of the
> port in the kernel used;
> - beaglebone using 3.8 fork: patch submitted, no feedback, no
> further submission; considered bitroting now
> - raspberry: same as beaglebone
> - zynq: two patches submitted, one for 3.5 and one for 3.8, but
> otherwise same as beaglebone and raspberry.
> 
> In my experience, when people choose a kernel version for an
> industrial project, they tend to stick to that version for the
> duration of the project, or even for all the projects they do with
> the same processors. The result is that if they need an I-pipe patch
> for their project, they need it for one kernel version, so their
> contribution is of the "drop and go" kind. Simply because when this
> project is finished, another starts, maybe using a newer processor,
> and so they never get the time to upgrade the patch to a kernel
> version they do not need.

We make products for the long term (in production for 10+ years) with
new features and support along the way.  We try to keep up with updates.
We will be moving our powerpc systems from 3.0 to 3.14 pretty soon.

> So, it is much better to contribute I-pipe patches to the mainline
> kernel I-pipe branch. Simply because, when I merge them, I
> compile-test them for every following supported mainline kernel
> release. So, even if some kernel change broke the patch without
> breaking compilation (this happens, and not even rarely), you have
> something from which you can start on a current release.
> 
> But my vendor fork supports hardware X or Y! Well, then port the
> driver for hardware X or Y to the mainline kernel, this will not
> take monthes to do (assuuming you will not try and get the drivers
> merged into mainline, because THAT would cost you a lot of time,
> there is a reason why vendors keep them in forks and do not try and
> merge them).

Well TI is working on mainlining support for the am572x at the moment,
but it looks like at best that will be in 3.19 at this point.  They will
probably also "officially" announce the am572x sometime soon, not that
it isn't mentioned in many places, including lots of public git trees
for linux.

There is a 3.8, 3.12 and 3.14 tree from ti at the moment.  3.12 works
quite well, although it has no dma controller driver.  3.14 has dma,
but is tricky to get to boot (have to get the config just right) and
is still under development.  The 3.8 tree just crashes user space apps
randomly and is useless.  So at the moment we use 3.12 with ipipe for
3.14 backported (was pretty simple to do), with the intent to go to 3.14
as soon as we get that working.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 04:39:31PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 10:17:13PM +0100, Gilles Chanteperdrix wrote:
> > It is not just TI. I believe all vendor forks have the same issue:
> > they are not written by people well versed into paying attention to
> > the kind of issue you have to pay attention to with Linux. Once
> > their patches get reviewed, of course they improve. But this takes a
> > lot of time, and for some drivers, they will not even make the
> > effort.
> 
> Certainly true.
> 
> > That being said, the last two vendor forks I used are for TI DM8148,
> > and Xilinx Zynq, and I have to admit that the TI DM8148 fork  code
> > is much much worse than the Xilinx one.
> > 
> > Ok, it seems the TI mainline maintainers are less sloppy, the kernel
> > compiles and boot on both platforms. Less sloppy only because on my
> > OMAP3 board, the USB controller does not get initialized.
> 
> TI seems to be on a 'Get it mainlined' kick lately, so perhaps they are
> being more careful as a result.

>From what I was told by someone who knew  someone who talked to
someone, this was actually actually a two step process (I do not
know whether this changed).

An team did the work that went into the kernel fork that was
delivered to customers, with rapid delivery date as the priority
goal.

Then in a second time, a different team started writing the code
that went into mainline, I am not even sure it used the code of the
first team.

> 
> > Anyway, this is not a good solution, this is clearly something that
> > nobody tests, thre is no reason to expect it what we would expect to
> > dot. 
> 
> I see this 'hack' in the omap timer code:
> 
> +#ifdef CONFIG_IPIPE
> +       if (ipipe) {
> +               u32 l;
> +
> +               l = __raw_readl(timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> +               l = (0x3 << 8) | (l & (1 << 5)) | (0x1 << 3) | (1 << 2);
> +               __raw_writel(l, timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> +       }
> +#endif
> 
> Sure would be nice if someone had actually defined what those bits are,
> although it appears to be setting wakeup on, and idle mode to 'no idle',
> and I didn't look up the 5 and 8 bits yet.

I did that. And I prefer explicit bit numbers, because they match
the datasheet, which is the ultimate reference.

With code relying on defines, you have to trust the define names to
match what you think they do. And I have learned to never trust
identifier names, so I want to check the datasheet anyway, and the
defines do not help, because now instead of having just 4 fields to
check from the same line of code in the documentation of one
register, you have to find the 4 fields definitions in the
middle of a whole bunch of definitions in a separate header file,
and move back and forth.

So, the bottom line is, while I understand the values of defines to
provide the same name to the same bit, when used in several places,
as would be the case for software bitfield, I do not see the value
of it for register values.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 11:05:21PM +0100, Gilles Chanteperdrix wrote:
> From what I was told by someone who knew  someone who talked to
> someone, this was actually actually a two step process (I do not
> know whether this changed).
> 
> An team did the work that went into the kernel fork that was
> delivered to customers, with rapid delivery date as the priority
> goal.
> 
> Then in a second time, a different team started writing the code
> that went into mainline, I am not even sure it used the code of the
> first team.

Well there is also the question of whether it is the network group or
automotive group doing it (sometimes even for the same chip).

It does appear that the code is getting reused from the bits I have seen
getting mainlines, although at least some of it has needed some cleanups.

> I did that. And I prefer explicit bit numbers, because they match
> the datasheet, which is the ultimate reference.
> 
> With code relying on defines, you have to trust the define names to
> match what you think they do. And I have learned to never trust
> identifier names, so I want to check the datasheet anyway, and the
> defines do not help, because now instead of having just 4 fields to
> check from the same line of code in the documentation of one
> register, you have to find the 4 fields definitions in the
> middle of a whole bunch of definitions in a separate header file,
> and move back and forth.
> 
> So, the bottom line is, while I understand the values of defines to
> provide the same name to the same bit, when used in several places,
> as would be the case for software bitfield, I do not see the value
> of it for register values.

If you don't remember which bit is which, having names for them helps you
remember what the code does.  Or at least put a comment saying "Disabling
idle and enabling wakeup, etc".

Magic numbers with no explanation are terrible when reading the code.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Tue, Nov 18, 2014 at 05:31:23PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 11:05:21PM +0100, Gilles Chanteperdrix wrote:
> > From what I was told by someone who knew  someone who talked to
> > someone, this was actually actually a two step process (I do not
> > know whether this changed).
> > 
> > An team did the work that went into the kernel fork that was
> > delivered to customers, with rapid delivery date as the priority
> > goal.
> > 
> > Then in a second time, a different team started writing the code
> > that went into mainline, I am not even sure it used the code of the
> > first team.
> 
> Well there is also the question of whether it is the network group or
> automotive group doing it (sometimes even for the same chip).
> 
> It does appear that the code is getting reused from the bits I have seen
> getting mainlines, although at least some of it has needed some cleanups.
> 
> > I did that. And I prefer explicit bit numbers, because they match
> > the datasheet, which is the ultimate reference.
> > 
> > With code relying on defines, you have to trust the define names to
> > match what you think they do. And I have learned to never trust
> > identifier names, so I want to check the datasheet anyway, and the
> > defines do not help, because now instead of having just 4 fields to
> > check from the same line of code in the documentation of one
> > register, you have to find the 4 fields definitions in the
> > middle of a whole bunch of definitions in a separate header file,
> > and move back and forth.
> > 
> > So, the bottom line is, while I understand the values of defines to
> > provide the same name to the same bit, when used in several places,
> > as would be the case for software bitfield, I do not see the value
> > of it for register values.
> 
> If you don't remember which bit is which, having names for them helps you
> remember what the code does.  Or at least put a comment saying "Disabling
> idle and enabling wakeup, etc".

Ok for the comment. I trust comments even less than I trust
identifier names, but I understand other would like them when
reading the code.

> 
> Magic numbers with no explanation are terrible when reading the code.

This applies to software bitmap I agree, but having made it a
general rule and apply it indiscriminately is wrong. Register values
are magic values, whether you want it or not, the only way to
understand code writing to registers is using the datasheet.

Adding defines for register bits is just adding a layer of things
which could not do what they appear to do. Incidentally, in TI code
it already happened to me to bang my head against the wall because a
register write did not work as expected, only to find out that the
define in the header was wrong due to a cut and paste error.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Tue, Nov 18, 2014 at 04:39:31PM -0500, Lennart Sorensen wrote:
> TI seems to be on a 'Get it mainlined' kick lately, so perhaps they are
> being more careful as a result.
> 
> > Anyway, this is not a good solution, this is clearly something that
> > nobody tests, thre is no reason to expect it what we would expect to
> > dot. 
> 
> I see this 'hack' in the omap timer code:
> 
> +#ifdef CONFIG_IPIPE
> +       if (ipipe) {
> +               u32 l;
> +
> +               l = __raw_readl(timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> +               l = (0x3 << 8) | (l & (1 << 5)) | (0x1 << 3) | (1 << 2);
> +               __raw_writel(l, timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> +       }
> +#endif
> 
> Sure would be nice if someone had actually defined what those bits are,
> although it appears to be setting wakeup on, and idle mode to 'no idle',
> and I didn't look up the 5 and 8 bits yet.
> 
> I was hoping to do something a lot cleaner than that.

Well this works for me:

Index: linux-3.12.31.rr1/arch/arm/mach-omap2/omap_hwmod.c
===================================================================
--- linux-3.12.31.rr1.orig/arch/arm/mach-omap2/omap_hwmod.c     2014-11-19 11:32:38.931715225 -0500
+++ linux-3.12.31.rr1/arch/arm/mach-omap2/omap_hwmod.c  2014-11-19 12:08:45.575792706 -0500
@@ -2587,6 +2587,8 @@
                        oh->flags |= HWMOD_INIT_NO_RESET;
                if (of_find_property(np, "ti,no-idle", NULL))
                        oh->flags |= HWMOD_INIT_NO_IDLE;
+               if (of_find_property(np, "ti,no-smart-idle", NULL))
+                       oh->flags |= HWMOD_SWSUP_SIDLE;
        }
 
        oh->_state = _HWMOD_STATE_INITIALIZED;

combined with adding to the dts:

&gpio7 {
	ti,no-smart-idle;
};

I think I like that as a simple clean solution.

Now the SYSCONFIG register is 0x0009 (no idle + autoidle) rather than
0x001d (smart idle with wakeup enabled + autoidle)

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Wed, Nov 19, 2014 at 12:12:04PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 04:39:31PM -0500, Lennart Sorensen wrote:
> > TI seems to be on a 'Get it mainlined' kick lately, so perhaps they are
> > being more careful as a result.
> > 
> > > Anyway, this is not a good solution, this is clearly something that
> > > nobody tests, thre is no reason to expect it what we would expect to
> > > dot. 
> > 
> > I see this 'hack' in the omap timer code:
> > 
> > +#ifdef CONFIG_IPIPE
> > +       if (ipipe) {
> > +               u32 l;
> > +
> > +               l = __raw_readl(timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> > +               l = (0x3 << 8) | (l & (1 << 5)) | (0x1 << 3) | (1 << 2);
> > +               __raw_writel(l, timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> > +       }
> > +#endif
> > 
> > Sure would be nice if someone had actually defined what those bits are,
> > although it appears to be setting wakeup on, and idle mode to 'no idle',
> > and I didn't look up the 5 and 8 bits yet.
> > 
> > I was hoping to do something a lot cleaner than that.
> 
> Well this works for me:
> 
> Index: linux-3.12.31.rr1/arch/arm/mach-omap2/omap_hwmod.c
> ===================================================================
> --- linux-3.12.31.rr1.orig/arch/arm/mach-omap2/omap_hwmod.c     2014-11-19 11:32:38.931715225 -0500
> +++ linux-3.12.31.rr1/arch/arm/mach-omap2/omap_hwmod.c  2014-11-19 12:08:45.575792706 -0500
> @@ -2587,6 +2587,8 @@
>                         oh->flags |= HWMOD_INIT_NO_RESET;
>                 if (of_find_property(np, "ti,no-idle", NULL))
>                         oh->flags |= HWMOD_INIT_NO_IDLE;
> +               if (of_find_property(np, "ti,no-smart-idle", NULL))
> +                       oh->flags |= HWMOD_SWSUP_SIDLE;
>         }
>  
>         oh->_state = _HWMOD_STATE_INITIALIZED;
> 
> combined with adding to the dts:
> 
> &gpio7 {
> 	ti,no-smart-idle;
> };
> 
> I think I like that as a simple clean solution.
> 
> Now the SYSCONFIG register is 0x0009 (no idle + autoidle) rather than
> 0x001d (smart idle with wakeup enabled + autoidle)

I do not know what to say. At software level, it is not really hard
to get the I-pipe code to trigger a write to a register when the
first RT irq is enabled in a bank and another write when the last RT
irq gets disabled, because we keep track of that in the
enable_irqdesc/disable_irqdesc callbacks.

Now, I suspect hwmod is made to be transparent, and called when
initializing the bank, way before an irq is enabled, so the
behaviour can not really be influenced from enable_irqdesc/disable_irqdesc.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Nov 19, 2014 at 11:38:48PM +0100, Gilles Chanteperdrix wrote:
> I do not know what to say. At software level, it is not really hard
> to get the I-pipe code to trigger a write to a register when the
> first RT irq is enabled in a bank and another write when the last RT
> irq gets disabled, because we keep track of that in the
> enable_irqdesc/disable_irqdesc callbacks.

Sure, but other power management calls to the hardware is allowed to
change the register too at any time.  By setting the flag I make sure
the other calls will NEVER enable smartidle.  So making it a dtb option
means the board maker gets to specify that they want smartidle off for
a given piece of hardware.  I did want to make it only get changed when
an IRQ was enabled but that was a mess given it is in a totally different
part of the code.

> Now, I suspect hwmod is made to be transparent, and called when
> initializing the bank, way before an irq is enabled, so the
> behaviour can not really be influenced from enable_irqdesc/disable_irqdesc.

That is certainly true.  It is called when the hardware is probed.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Thu, Nov 20, 2014 at 03:01:33PM -0500, Lennart Sorensen wrote:
> On Wed, Nov 19, 2014 at 11:38:48PM +0100, Gilles Chanteperdrix wrote:
> > I do not know what to say. At software level, it is not really hard
> > to get the I-pipe code to trigger a write to a register when the
> > first RT irq is enabled in a bank and another write when the last RT
> > irq gets disabled, because we keep track of that in the
> > enable_irqdesc/disable_irqdesc callbacks.
> 
> Sure, but other power management calls to the hardware is allowed to
> change the register too at any time.

Then we have a problem, because once the irq has been enabled for
Xenomai, it is almost certainly wrong for a power management call to
change its register. So, probably power management should be
disabled like on x86.

>  By setting the flag I make sure
> the other calls will NEVER enable smartidle.  So making it a dtb option
> means the board maker gets to specify that they want smartidle off for
> a given piece of hardware.  I did want to make it only get changed when
> an IRQ was enabled but that was a mess given it is in a totally different
> part of the code.

Yes that I what I meant, getting back the pointer to the structure
needed by the hwmod layer is going to be hard, since this pointer is
well hidden under the carpet.

Anyway, if anyone wants a better solution, he will implement it, I
will merge your patch in the current version of the I-pipe patch
(3.16.0).

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Thu, Nov 20, 2014 at 09:06:39PM +0100, Gilles Chanteperdrix wrote:
> Then we have a problem, because once the irq has been enabled for
> Xenomai, it is almost certainly wrong for a power management call to
> change its register. So, probably power management should be
> disabled like on x86.

Perhaps, but TI's code doesn't compile if you turn it off at the moment.

> Yes that I what I meant, getting back the pointer to the structure
> needed by the hwmod layer is going to be hard, since this pointer is
> well hidden under the carpet.
> 
> Anyway, if anyone wants a better solution, he will implement it, I
> will merge your patch in the current version of the I-pipe patch
> (3.16.0).

I was even thinking of sending it upstream for suggestions.  Others using
linux might want fast interrupts too.  But certainly useful for ipipe
users so far.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Thu, Nov 20, 2014 at 05:38:17PM -0500, Lennart Sorensen wrote:
> On Thu, Nov 20, 2014 at 09:06:39PM +0100, Gilles Chanteperdrix wrote:
> > Then we have a problem, because once the irq has been enabled for
> > Xenomai, it is almost certainly wrong for a power management call to
> > change its register. So, probably power management should be
> > disabled like on x86.
> 
> Perhaps, but TI's code doesn't compile if you turn it off at the moment.
> 
> > Yes that I what I meant, getting back the pointer to the structure
> > needed by the hwmod layer is going to be hard, since this pointer is
> > well hidden under the carpet.
> > 
> > Anyway, if anyone wants a better solution, he will implement it, I
> > will merge your patch in the current version of the I-pipe patch
> > (3.16.0).
> 
> I was even thinking of sending it upstream for suggestions.  Others using
> linux might want fast interrupts too.  But certainly useful for ipipe
> users so far.

Oh my, another Don Quijote. My prognostic: "the device tree is a
description of the hardware and should not contain such parameters".
But go ahead, try it.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On Thu, Nov 20, 2014 at 05:38:17PM -0500, Lennart Sorensen wrote:
> On Thu, Nov 20, 2014 at 09:06:39PM +0100, Gilles Chanteperdrix wrote:
> > Then we have a problem, because once the irq has been enabled for
> > Xenomai, it is almost certainly wrong for a power management call to
> > change its register. So, probably power management should be
> > disabled like on x86.
> 
> Perhaps, but TI's code doesn't compile if you turn it off at the moment.

Mainline TI code does, as I said, I just have a few issues, but
fixing them look really doable. Alternatively, we could, with a
#ifdef CONFIG_IPIPE define a few of the bits used in omap_hwmod to
0, so as to avoid the use of smart-idle.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Fri, Nov 21, 2014 at 08:59:00AM +0100, Gilles Chanteperdrix wrote:
> Mainline TI code does, as I said, I just have a few issues, but
> fixing them look really doable. Alternatively, we could, with a
> #ifdef CONFIG_IPIPE define a few of the bits used in omap_hwmod to
> 0, so as to avoid the use of smart-idle.

Certainly an option.  I think I will get some feedback from the maintainer
of the driver to see what they think of the idea.

-- 
Len Sorense