[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFVXLMtEOuXFL8B-@finisterre.sirena.org.uk>
Date: Fri, 20 Jun 2025 13:42:20 +0100
From: Mark Brown <broonie@...nel.org>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>
Cc: Shengjiu Wang <shengjiu.wang@....com>, lgirdwood@...il.com,
perex@...ex.cz, tiwai@...e.com, patches@...nsource.cirrus.com,
linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
shengjiu.wang@...il.com
Subject: Re: [PATCH v3] ASoC: wm8524: enable constraints when sysclk is
configured.
On Fri, Jun 20, 2025 at 09:42:58AM +0100, Charles Keepax wrote:
> On Fri, Jun 20, 2025 at 09:26:00AM +0100, Charles Keepax wrote:
> > This is kinda the opposite of what I was hoping we could do. The
> > idea was to make sure we returned an error if we can't support
> > the given rate. So if we don't have the constraint, we check the
> > value in hw_params. This looks like it checks in hw_params only
> > in the case the constraint existed, but in that case there is no
> > need to check because we had the constraint.
> Although perhaps I am mistaken here, I guess is the clock has
> been set by the machine driver then we would pass this check.
> Would it perhaps make more sense to return an error rather than
> zero here?
The link hw_params() should be run before the CODEC ones so we would be
able to insist on the clocks having been configured first.
Or I wonder if it might be easier to just implement clock API support in
the driver and if we get a MCLK we set it to a sensible value here?
That wouldn't work if the MCLK is coming from the other DAI though.
Also I'm really not sure how this bikeshed fits into the design concept
here.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists