From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Paul Walmsley <paul@pwsan.com>, Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
Tony Lindgren <tony@atomide.com>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, Tero Kristo <t-kristo@ti.com>,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [PATCH 3/3] ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3
Date: Mon, 21 Mar 2016 10:44:38 +0200 [thread overview]
Message-ID: <56EFB476.70709@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1603191932240.6629@utopia.booyaka.com>
Paul,
On 03/19/16 21:37, Paul Walmsley wrote:
> 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@ti.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.
I can not recall such a flag. We had both hwmods attached to the given McBSP
mkodule via dev_attr and we dealt with the McBSP_ICLK autoidle enable/disable
via callbacks provided to the driver via platform data.
arch/arm/mach-omap2/mcbsp.c: omap3_enable_st_clock() In there we use
omap2_clk_deny_idle()/omap2_clk_allow_idle() to make sure that the ICLK is not
gated when the ST is enabled in the given McBSP module.
But this only works when we boot in legacy mode. The DT boot is broken in this
regards as long we have first booted OMAP3 with DT.
--
Péter
next prev parent reply other threads:[~2016-03-21 8:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 10:28 [PATCH 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone Peter Ujfalusi
2016-03-18 10:28 ` [PATCH 1/3] ARM: DTS: omap3: Remove mcbsp2/3_sidetone hwmod reference for McBSP2/3 Peter Ujfalusi
2016-03-18 10:28 ` [PATCH 2/3] ARM: OMAP3: hwmod data: Merge and remove the McBSP sidetone related data Peter Ujfalusi
2016-03-18 14:09 ` Peter Ujfalusi
2016-03-18 10:28 ` [PATCH 3/3] ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3 Peter Ujfalusi
[not found] ` <1458296929-718-4-git-send-email-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
2016-03-19 19:37 ` Paul Walmsley
2016-03-21 8:44 ` Peter Ujfalusi [this message]
[not found] ` <alpine.DEB.2.02.1603191932240.6629-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2016-03-21 9:52 ` Mark Brown
2016-03-19 19:31 ` [PATCH 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone Paul Walmsley
2016-03-21 8:38 ` Peter Ujfalusi
[not found] ` <56EFB31C.9090103-l0cyMroinI0@public.gmane.org>
2016-03-21 20:21 ` Tony Lindgren
2016-03-22 8:53 ` Peter Ujfalusi
[not found] ` <56F107FF.8080006-l0cyMroinI0@public.gmane.org>
2016-03-22 19:29 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56EFB476.70709@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jarkko.nikula@bitmer.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).