Re: [pandaboard] audio initialization fails due to TWL6040

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [140108 05:25]:
> 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.

It seems that this you may be able to sort out just by exporting a function
from the ST code for the McBSP to call, and for the autoidle, can't you..
 
> 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.

..just use runtime PM calls from the ST module?
 
> 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.

OK
 
> The Sidetone address space also have sysconfig register with AUTOIDLE bit, but
> it has no effect on the McBSP_ICLK autoidle itself.

Yes that's because they're separate hardware modules like we have them in
the hwmod code :)

> 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.

It seems that runtime PM should be able to do that. But maybe I'm missing
something here.

Regards,

Tony
--
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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux