[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yp9CoibeiXff43//@sirena.org.uk>
Date: Tue, 7 Jun 2022 13:20:50 +0100
From: Mark Brown <broonie@...nel.org>
To: Lukasz Majewski <lukma@...x.de>
Cc: Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
patches@...nsource.cirrus.com, alsa-devel@...a-project.org,
Takashi Iwai <tiwai@...e.com>, Jaroslav Kysela <perex@...ex.cz>
Subject: Re: [PATCH 2/3] ASoC: wm8940: Rewrite code to set proper clocks
On Tue, Jun 07, 2022 at 02:13:09PM +0200, Lukasz Majewski wrote:
> > On Mon, Jun 06, 2022 at 05:44:40PM +0200, Lukasz Majewski wrote:
> > I don't entirely follow the above - in what way might the core adjust
> > the clocking, and why would we want to allow the use of invalid
> > clocks? Surely that just makes error checking worse.
> Hmm, it is a bit complicated.
> When I enabed wm8940 support in mainline - the first call to
> wm8940_set_dai_sysclk (the set_sysclk callback) required mclk = 11997070
> frequency.
> With the current code [1] the initialization of the codec returns
> -EINVAL and the codec is not supported in the system:
> asoc-simple-card: probe of sound failed with error -22
Well, that looks like a bug in either simple-card or it's configuration
which should be fixed then (you should probably use audio-graph-card for
new things BTW). If a machine driver just randomly sets a clock rate
that the system can't support and doesn't want then that's a problem,
presuambly it's getting that rate from somewhere. Note that this is the
machine driver trying to set a clock rate, not the core.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists