On Thu, 18 Jun 2009 13:40:56 +0200 Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> wrote: > Then I retired the same on the commit > d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup. > Next, I moved mcbsp initialization to a boot time hook and finally > heard a sound and got my first DMA interrupt! > Great! :-) I wonder what special boot time omap_mcbsp_request call has in respect to McBSP access. DSP issue pointed by Tony might be one answer and I'm also thinking can it be also some clock gating problem to the McBSP like some parent clock gets idled after booting? Can you move this boot time initialization moment around with xxx_initcall variants to see what is the point where block is not anymore accessable? Basically around the DSP power up and idle code (were there such code for older audio drivers?) and where unused clocks are disabled (functions clk_disable_unused and omap1_clk_disable_unused). -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
