Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 15 Mar 2021 15:39:25 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Sameer Pujar <spujar@nvidia.com>
Cc:     Michael Walle <michael@walle.cc>, alsa-devel@alsa-project.org,
        devicetree@vger.kernel.org, jonathanh@nvidia.com,
        kuninori.morimoto.gx@renesas.com, linux-kernel@vger.kernel.org,
        linux-tegra@vger.kernel.org, robh@kernel.org, sharadg@nvidia.com,
        thierry.reding@gmail.com
Subject: Re: [PATCH 1/3] ASoC: simple-card-utils: Fix device module clock
Message-ID: <20210315153925.GC4595@sirena.org.uk>
References: <ca540fb6-2ea7-90b0-66ad-097e99b6e585@nvidia.com>
 <20210311161558.GG4962@sirena.org.uk>
 <f21b87f1afb3eda54b5f00f2d1c146d3@walle.cc>
 <20210312113544.GB5348@sirena.org.uk>
 <6ed28bb5330879b1919aced5174f319f@walle.cc>
 <20210312120456.GD5348@sirena.org.uk>
 <684332700f8be9f77348a510eb6eba22@walle.cc>
 <20210312134642.GF5348@sirena.org.uk>
 <8cdf1cfa971945792b509a687a4de735@walle.cc>
 <6af6439c-bdb8-cd0f-635d-069040ba5b65@nvidia.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="uXxzq0nDebZQVNAZ"
Content-Disposition: inline
In-Reply-To: <6af6439c-bdb8-cd0f-635d-069040ba5b65@nvidia.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--uXxzq0nDebZQVNAZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Mar 15, 2021 at 08:49:00PM +0530, Sameer Pujar wrote:
> On 3/15/2021 5:35 PM, Michael Walle wrote:
> > Am 2021-03-12 14:46, schrieb Mark Brown:

> > Sameer, it looks like the proper fix should be to add the clock
> > support to your codec.

> I agree that complicated clock relationships should be handled within the
> codec itself, however MCLK rate setting depends on "mclk-fs" factor and this
> property is specified as part of simple-card/audio-graph-card codec subnode.
> Right now codec, in general, does not have a way to know this. The
> set_sysclk() callback takes rate argument and not the factor. Moreover the

I just don't understand what you're saying here at all.  At the point
where the card is setting the clock API clock rate it can just as well
set a sysclk, these are equivalent operations.

> same codec is used by other platform vendors too and unless a new DT
> property is added for codec, runtime MCLK update based on the scaling factor
> cannot be supported. This would mean that we will be having two methods to
> specify "mclk-fs" factor, one from simple-card/audio-graph-card and one from
> respective codec nodes, which does not seem ideal.

Again I just can't follow what you're saying here at all.  Again, if the
card is able to set a clock API clock rate it can just as well set a
clock rate via sysclk.

> Yes this is a problem, unfortunately I missed checking some of the
> simple-card examples. I wonder we should be specifically looking for "mclk"
> clock here.

That would definitely help mitigate the problem but I really think it's
cleaner and safer to just push this down to set_sysclk().

--uXxzq0nDebZQVNAZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmBPf6wACgkQJNaLcl1U
h9Anfwf+NP6HDFtTMIGn540KNLqeTA05Iyt+oW7RwSiBDgEcmupxmx+Zg3B5DtBv
91x/ITUTS+eelZ+Vt2drZY36xNxgj1rY5Zp0P4iI0+dsUabcPlueyYy34Rt8kjip
jyNpLbAJb4RjpfEVssyo2UGKRdon7YwHbz+zgBQt6dxUAumaQa9HrsNDZhxQxe/A
KAeErTEhg62Z9lazAxPupmgLZyGwa4E6z80yb4t6snS182xNsGGz1iwV0F+9Ccr6
Rw3bR3UXovnJXjv7sDgJGBL7MQ/W0TAs3wmbnkAYtQ2Px/WQgvvxPHgGN0cWebKE
xGoRNVLAazs4y/mJB7875+CfQ1plPA==
=Fwtg
-----END PGP SIGNATURE-----

--uXxzq0nDebZQVNAZ--