[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15d3fc6e-d294-4968-bc7d-66307efc92db@sirena.org.uk>
Date: Wed, 5 Jul 2023 20:21:58 +0100
From: Mark Brown <broonie@...nel.org>
To: Andreas Kemnade <andreas@...nade.info>
Cc: bcousson@...libre.com, tony@...mide.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
lgirdwood@...il.com, perex@...ex.cz, tiwai@...e.com,
peter.ujfalusi@...il.com, jarkko.nikula@...mer.com,
dmitry.torokhov@...il.com, linux-omap@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
alsa-devel@...a-project.org
Subject: Re: [PATCH 2/3] ASoC: tlv320aic3x: use BCLK instead of MCLK if not
in master mode
On Wed, Jul 05, 2023 at 09:03:23PM +0200, Andreas Kemnade wrote:
> + /* probably no mclk if not master, so rely on bitclk */
> + if (!aic3x->master)
> + clk_id = 2;
> +
This is fairly clearly a massive hack, we're just silently ignoring the
clock we were asked to configure and choosing another one which is
likely at a different rate to that we were expecting and sadly the
driver didn't provide an automatic mode due to how old it is. We also
appear to try to use the configured clock rate during PLL setup which
still happens in hw_params() even with this change which is a bit of a
concern here. Are you sure hw_params ends up doing the right thing, and
that there are no other systems that get broken by this (perhaps ones
sending a lower BCLK for example)?
It would be nicer to set the clock via the DT bindings, ideally with the
clock bindings...
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists