On Fri, 1 Jul 2011 03:23:49 -0600 (MDT) Paul Walmsley <p...@pwsan.com> wrote:
> 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 understood from the code that OCPIF_SWSUP_IDLE with clkops_omap2_dflt_wait in clock data means that then ICLK won't autoidle at all when clock is enabled? Normally, when not using the sidetone we want to have ICLK autoidling since then omap can idle when using threshold based transfers and McBSP FIFO. > Otherwise these direct register manipulations of clock registers, outside > the clock code, could turn into a mess :-( > I definitely agree. I was thinking some virtual clock for sidetone but that didn't sound good either since then both McBSP ICLK and virtual sidetone clock would be modifying the same register. Anyway, some omap device API for runtime autoidle bit setting sounds much better approach in enable_st_clock callback than hacking with clock registers. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
