Re: [pandaboard] audio initialization fails due to TWL6040

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 01/08/2014 12:53 AM, Tony Lindgren wrote:
> Well we cannot sanely deprecate the "ti,hwmods" and move on to
> matching hwmod data with DT data based on the compatible flag.
> So it's a bit of a blocker for v3.15 or so time frame.
>
>> Due to a 'hw feature' around the sidetone this is not as straight forward as
>> it sounds...
> 
> OK. The driver(s) should still be able to coordinate things
> to sort it out hopefully?

After a quick look at the code:
- sidetone _is_ broken when we boot with DT for sure already.
- sidetone works only if we boot in legacy mode.

While it is true that ST block has it's own address space and even dedicated
irq line, but..
ST can be enabled from the McBSP address space (via SSELCR_REG).
When ST is enabled we need to disable the corresponding McBSP's autoidle. The
reason for this is that the ST block is clocked from the McBSP IP's interface
clock. If the interface clock of the McBSP is idling there will be glitches in
the sidetone generation due to not having continuously running clock for it's
internals.

For legacy boot we had this handled by a custom callback to disable autoidle
for the McBSP when the ST starts and enable it back when ST is stopped:
arch/arm/mach-omap2/mcbsp.c:omap3_enable_st_clock() is the callback we call.

Normal audio will work via McBSP if we get rid of hwmod, the driver can load
and operate that way. As for the sidetone functionality: it is broken when we
boot with DT and the removal of hwmod will have no effect on this.

The Sidetone address space also have sysconfig register with AUTOIDLE bit, but
it has no effect on the McBSP_ICLK autoidle itself.
In theory we can handle the sidetone as we do right now, but we need one
thing: an API so drivers can disable/enable autoidle of an already enabled clock.

CCing Tero for this, he might have pointers or idea on how we can do this.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html