From: Joerg Schambacher <joerg.hifiberry@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: a-krasser@ti.com, joerg@hifiberry.com,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Jaroslav Kysela" <perex@perex.cz>,
"Takashi Iwai" <tiwai@suse.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Zhang Qilong" <zhangqilong3@huawei.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ASoC: Adds support for TAS575x to the pcm512x driver
Date: Mon, 11 Sep 2023 13:59:46 +0200 [thread overview]
Message-ID: <ZP8BMkDeZakUyACL@ubuntu> (raw)
In-Reply-To: <bb3e5ccf-6eb5-4a36-9af0-b33f2db68445@sirena.org.uk>
Am 07.09.2023 um 17:28 hat Mark Brown geschrieben:
> On Thu, Sep 07, 2023 at 06:21:50PM +0200, Joerg Schambacher wrote:
>
> > And yes, we cannot be sure that future devices may require different
> > settings, but I can hardly imagine anything completely different than
> > this approach with the usual audio MCLK frequencies.
>
> They may for example be restricted and just not the the incoming MCLK
> divider, or require a higher frequency for some fancy processing. In
> any case tas_device is just an obviously bad name here - there should be
> a flag per quirk, not a flag per entire class of devices.
>
Ok, I see your point and completely agree. I tend for now to leave that
part out of the patch. This leaves the PLL divider programmings
completely 'untouched'. Nevertheless, I'll continue with testing here
on the hardware.
> > > This is probably a separate quirk? I'm a bit concerned about what's
> > > turning the PLL off here...
>
> > The PLL should not be used in this specific case where all divisions are
> > just divide-by-2's. Your original code does reflect that and turns the
> > PLL off. It improves jitter and finally audio performance.
>
> > But in the case of the TAS-devices we even then need the PLL to
> > drive the AMP clocks.
>
> That's definitely a separate quirk, and does sound like it should be
> driven from the bias management or DAPM more than hw_params.
Then it makes sense to use a DT-param 'force_pll_on' and even
remove the compatible string fixes from the patch series.
Still, I think, this is the best part of the code to act on the PLL.
Simply instead of checking 'do we need it or not' just let it run.
What do you think?
--
next prev parent reply other threads:[~2023-09-11 21:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 16:12 [PATCH 2/2] ASoC: Adds support for TAS575x to the pcm512x driver Joerg Schambacher
2023-09-07 14:21 ` Mark Brown
2023-09-07 16:21 ` Joerg Schambacher
2023-09-07 16:28 ` Mark Brown
2023-09-11 11:59 ` Joerg Schambacher [this message]
2023-09-11 12:11 ` 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=ZP8BMkDeZakUyACL@ubuntu \
--to=joerg.hifiberry@gmail.com \
--cc=a-krasser@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=joerg@hifiberry.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=zhangqilong3@huawei.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