linux-kernel - Re: [PATCH 3/3] ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 Mar 2016 19:37:33 +0000 (UTC)
From:	Paul Walmsley <paul@...an.com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>,
	Mark Brown <broonie@...nel.org>
cc:	Tony Lindgren <tony@...mide.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jarkko Nikula <jarkko.nikula@...mer.com>,
	Tero Kristo <t-kristo@...com>, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: [PATCH 3/3] ASoC: omap-mcbsp: Enable/disable sidetone block auto
 clock gating for omap3

On Fri, 18 Mar 2016, Peter Ujfalusi wrote:

> OMAP3's McBSP2 and McBSP3 module have integrated sidetone block with
> dedicated SYSCONFIG register. The sidetone is operating from the maain
> McBSP module's ICLK. For normal operation the sidetone clock auto idle
> support needs to be disabled when it is activated.
> Note: This is not enough to avoid choppy sidetone because this AUTOIDLE
> bit is controlling only the clock auto idle from the McBSP to the sidetone
> block. If the McBSP_ICLK is idling, the sidetone clock is going to do the
> same.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>

Mark, please drop this patch for the time being, until the SoC integration 
issues can be sorted out first.  It's best to wait a little while before 
applying patches like these so folks have a chance to comment on their 
correctness first.

We used to handle this problem in the OMAP hwmod SoC integration layer 
with a flag that forced the interface clock to stay active as long as the 
underlying IP blocks were active.  However I can't find that flag right 
now in the current data, so maybe it got accidentally or inadvertently 
removed at some point in time in the past.  The right way to fix this 
would be to add that flag back in, rather than messing with the SoC 
integration registers from the McBSP drivers.

thanks

- Paul