+ Benoît Hello Jarkko On Fri, 1 Jul 2011, Jarkko Nikula wrote: > Active sidetone requires that McBSP interface clock doesn't idle and there > is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3 > in OMAP34xx share their interface clock with McBSP sidetone module and > that interface clock must be active when the sidetone is operating. > > Sidetone has its own autoidle bit which should keep the interface clock > active but it is broken. Putting the McBSP core to no-idle mode when the > sidetone is active is no good either since it results to higher power > consumption when using the threshold based DMA transfers. In the hwmod code/data, we've got the OCPIF_SWSUP_IDLE flag that can be set on a struct omap_hwmod_ocp_if. I think this is probably what's needed here. The only problem is that we haven't linked that to the clock code to deny idle on the interface clock yet (see omap_hwmod.c:_setup()). Adding that code in, plus adding that OCPIF_SWSUP_IDLE flag to the McBSP2/3 data, seems like the right approach here. I guess we also will need some basic usecounting for denying idle in the clock code. Otherwise these direct register manipulations of clock registers, outside the clock code, could turn into a mess :-( At least it makes sense to move those out of the driver and into the arch/arm/*omap* code... - Paul