From: "Péter Ujfalusi" <peter.ujfalusi@gmail.com>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: Tony Lindgren <tony@atomide.com>,
bcousson@baylibre.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz,
tiwai@suse.com, jarkko.nikula@bitmer.com,
dmitry.torokhov@gmail.com, linux-omap@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org
Subject: Re: [PATCH 1/3] ASoC: ti: omap-mcbsp: Ignore errors for getting fck_src
Date: Wed, 25 Oct 2023 17:21:12 +0300 [thread overview]
Message-ID: <a0db9dbb-df0e-406a-9a88-2a6968ec1469@gmail.com> (raw)
In-Reply-To: <20231013132503.25d63933@aktux>
On 13/10/2023 14:25, Andreas Kemnade wrote:
>> I guess it is because of the pm_runtime_put_sync() in the
>> omap2_mcbsp_set_clks_src() around the fclk re-parenting.
>> That is a bit dubious thing for sure. We need to disable the device to
>> be able to re-parent the fclk but if we disable the device it is going
>> to be powered down, right? I think we have appropriate context handling,
>> so it might work, but it is certainly not a rock solid code... If you
>> have a stream running already, you don't really want to kill the McBSP.
>>
> Ok, so if the device is powered of at omap2_mcbsp_set_clks_src()
> we get the usage count underflow, and the counter is incremented
> immediately again in the runtime put function. So things get out of balance...
> I'll check Tony's fix here.
>
>> The problem is that this mux is outside of the McBSP IP, so we need a
>> system level (iow, clk API) way to change it runtime.
>>
>> What is the machine driver where this happens? If you set the sysclk in
>> hw_params of the machine driver, it will be OK, but if you do that in
>> probe time then it is likely going to fail as you experienced
>>
> As you see in the other patches of this series,
> it is a simple-audio-card with a tlv320aic3x codec
> in combination with the mcbsp.
To be honest I would be happier if we can just remove the whole
omap2_mcbsp_set_clks_src() and leave the CLKS source selection outside
of the driver.
But omap3pandora is selecting external clock as parent
(OMAP_MCBSP_SYSCLK_CLKS_EXT - in hw_params, so it actually works) and I
don't know what happens if this functionality is removed. Likely going
to break Pandora.
That is fixable, but what worries me is this comment and code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/ti/omap-mcbsp.c#n388
Which is added by me a long time ago:
e386615c01d37 ("ASoC: omap-mcbsp: When closing the port select PRCM
source for CLKS signal")
I'm not sure if this is possible to do in any other way.
--
Péter
next prev parent reply other threads:[~2023-10-25 14:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-05 19:03 [PATCH 0/3] ARM: omap4: embt2ws: Add audio support Andreas Kemnade
2023-07-05 19:03 ` [PATCH 1/3] ASoC: ti: omap-mcbsp: Ignore errors for getting fck_src Andreas Kemnade
2023-09-19 18:25 ` Péter Ujfalusi
2023-09-20 6:33 ` Tony Lindgren
2023-09-20 14:52 ` Andreas Kemnade
2023-09-20 17:24 ` Péter Ujfalusi
2023-09-20 17:40 ` Péter Ujfalusi
2023-09-21 12:16 ` Tony Lindgren
2023-10-06 10:23 ` Tony Lindgren
2023-10-06 19:30 ` Andreas Kemnade
2023-10-07 6:25 ` Tony Lindgren
2023-10-07 7:11 ` Andreas Kemnade
2023-10-07 7:41 ` Tony Lindgren
2023-10-07 8:34 ` Andreas Kemnade
2023-10-12 14:41 ` Péter Ujfalusi
2023-10-13 11:25 ` Andreas Kemnade
2023-10-25 14:21 ` Péter Ujfalusi [this message]
2023-10-15 21:48 ` Andreas Kemnade
2023-10-18 5:23 ` Tony Lindgren
2023-10-18 6:21 ` Andreas Kemnade
2023-07-05 19:03 ` [PATCH 2/3] ASoC: tlv320aic3x: use BCLK instead of MCLK if not in master mode Andreas Kemnade
2023-07-05 19:21 ` Mark Brown
2023-07-05 19:56 ` Andreas Kemnade
2023-07-06 12:02 ` Mark Brown
2023-07-08 13:03 ` Andreas Kemnade
2023-07-10 16:36 ` Mark Brown
2023-07-05 19:03 ` [PATCH 3/3] ARM: dts: omap4: embt2ws: Add audio support Andreas Kemnade
2023-07-05 19:23 ` Mark Brown
2023-07-19 17:47 ` (subset) [PATCH 0/3] ARM: " Mark Brown
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=a0db9dbb-df0e-406a-9a88-2a6968ec1469@gmail.com \
--to=peter.ujfalusi@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=andreas@kemnade.info \
--cc=bcousson@baylibre.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jarkko.nikula@bitmer.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=perex@perex.cz \
--cc=robh+dt@kernel.org \
--cc=tiwai@suse.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).