Tuesday, December 6, 2011

tidspbridge for 3.2

Early in the 3.2 development (3.2-rc1) I faced some tidspbridge issues with recent changes on dm_timer framework and module.h.

After looking at the issues, few patches were created:

1. [PATCH] staging: tidspbridge: include module.h by default
  • Made to fix a compilation break if you compile tidspbridge as part of the kernel. 

2. [PATCH v2] staging: tidspbridge: request dmtimer clocks on init
  • Recent changes to dm_timer framework, specifically the one that get the parent clock handles to set new source to a specific clock, make lockdep to complain when requesting dm timer clocks within a hardirq or softirq. In tidspbridge, this was changed to request the clocks on module load.
  • The dm timer framework also changed the behavior of ..._request* calls, given that the clocks are no longer returned in enable state, explicit calls were added in tidspbridge to enable/disable the clocks.
  • BUG:
  • An infinite loop with the following message:
    ------------[ cut here ]------------
    WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:161 omap3_l3_app_irq+0xd0/0x12c()
    In-band Error seen by IVA_SS  at address 0
    Modules linked in: mailbox_mach bridgedriver(C) mailbox
    [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x4c/0x64)
    [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40)
    [] (warn_slowpath_fmt+0x30/0x40) from [] (omap3_l3_app_irq+0xd0/0x12c)
    [] (omap3_l3_app_irq+0xd0/0x12c) from [] (handle_irq_event_percpu+0x5c/0x22c)
    [] (handle_irq_event_percpu+0x5c/0x22c) from [] (handle_irq_event+0x3c/0x5c)
    [] (handle_irq_event+0x3c/0x5c) from [] (handle_level_irq+0xac/0x130)
    [] (handle_level_irq+0xac/0x130) from [] (generic_handle_irq+0x30/0x48)
    [] (generic_handle_irq+0x30/0x48) from [] (handle_IRQ+0x4c/0xac)
    [] (handle_IRQ+0x4c/0xac) from [] (__irq_svc+0x3c/0xe0)
    [] (__irq_svc+0x3c/0xe0) from [] (__do_softirq+0x78/0x200)
    [] (__do_softirq+0x78/0x200) from [] (irq_exit+0x98/0xb4)
    [] (irq_exit+0x98/0xb4) from [] (handle_IRQ+0x50/0xac)
    [] (handle_IRQ+0x50/0xac) from [] (__irq_svc+0x3c/0xe0)
    [] (__irq_svc+0x3c/0xe0) from [] (__delay+0x0/0xc)
    ---[ end trace e028a0afcbe16fc7 ]---
    
    Which is caused because the dsp wants to access to gp timer registers, but tidspbridge failed to power on the clocks for those registers.

    Also here, you can find a sample module to prove the scenario that triggers lockdep error. 

3. [PATCH] ARM: OMAP: dmtimer: fix missing content/correction in low-power mode support
  • Somehow this code didn't make it to mainline when pushing the other patch series. Without this patch, dm timers start/stop sequence doesn't work.
  • BUG:
  • modprobe bridgedriver
    cexec.out <your baseimage>
    modprobe -r bridgedriver
    modprobe bridgedriver
    Will throw:
    omap_timer omap_timer.5: omap2_dm_timer_set_src: clk_set_parent() to 32k_ck FAILED
    omap_timer omap_timer.6: omap2_dm_timer_set_src: clk_set_parent() to 32k_ck FAILED
    

Now you know, in case you happen to try something while these patches are accepted. Hopefully they will before final 3.2, 1 & 2 were pushed to staging-next and not staging-linus :/ (working on it) and haven't seen 3 reposted (tracking it too).

No comments:

Post a Comment