Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 2 Jun 2023 13:19:08 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Alvin =?utf-8?Q?=C5=A0ipraga?= <ALSI@bang-olufsen.dk>
Cc:     Alvin =?utf-8?Q?=C5=A0ipraga?= <alvin@pqrs.dk>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] ASoC: dt-bindings: document new symmetric-clock-role
 flag
Message-ID: <91b6d02a-25d5-4835-942e-3f8072bd8897@sirena.org.uk>
References: <20230602090322.1876359-1-alvin@pqrs.dk>
 <20230602090322.1876359-2-alvin@pqrs.dk>
 <3fe93662-82b0-4834-b6c3-473669c66210@sirena.org.uk>
 <7csvw25vhyal2jsznb3jykuijxqpk7bzyguxvl7cyitosgga2w@pxmkce22cm3d>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="eKLqXSuhsjfwfQXk"
Content-Disposition: inline
In-Reply-To: <7csvw25vhyal2jsznb3jykuijxqpk7bzyguxvl7cyitosgga2w@pxmkce22cm3d>
Precedence: bulk


--eKLqXSuhsjfwfQXk
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 02, 2023 at 12:12:52PM +0000, Alvin =C5=A0ipraga wrote:
> On Fri, Jun 02, 2023 at 12:43:51PM +0100, Mark Brown wrote:

> > Why would we have a property for this and not just describe whatever the
> > actual clocking arrangement is?

> Sure - let me just elaborate on my thinking and maybe you can help me wit=
h a
> better approach:

> The clocking arrangement is encoded in the dai_fmt field of snd_soc_dai_l=
ink,
> but this is a single value that describes the format on both ends. The cu=
rrent
> behaviour of ASoC is to flip the clock roles encoded in dai_fmt when appl=
ying it
> to the CPU side of the link.

> Looking from a DT perspective, if I do not specify e.g. bitclock-master on
> either side of the link, then the dai_fmt will describe the codec as a bi=
tclock
> consumer and (after flipping) the CPU as a provider. That's the default
> implication of the DT bindings and I can't break compatibility there.

None of this addresses my question.  To repeat why would we not just
describe the actual clocking arrangement here - this property does not
specify where the clock actually comes from at all, we're still going to
need additional information for that and if we've described that clock
then we already know it's there without having to specify any more
properties.

> The other issue is that for the simple-card the DAI format is only parsed=
 in one
> place and applied to the whole link. Are you proposing that it be modifie=
d to
> explicitly try and parse both ends in order to determine if both sides wa=
nt to
> be clock consumers? In that case I'd have to also introduce bitclock-cons=
umer
> and frameclock-consumer properties to mirror the existing bitclock-master=
 and
> frameclock-master properties, as an explicit absence of the *-master prop=
erty on
> both sides would have to default to the original ASoC behaviour described=
 above.

If simple-card can't be made to work that's fine, it's deprecated
anyway.

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

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmR53jsACgkQJNaLcl1U
h9AqQgf+Jtc2Ihjbp82B3yzWnRCVZupKiJ+T2iC3qd0hfq3+jWz+RFnFHdNMk1Zw
iXOOvYCFENv9fZ3QnfkSGDXxEFfoPxPMaHZw3TgCWz3SjjotWePvHqRbEsvEOYFk
IB9Qp1phuf/2LLkB7wowMhaPjieW0MM2ju5LtpR8Ghf/f1Uq2GsI5cyHqme/9vd0
0q4Ti4HqvkAcrxIFsxp/PAY2z16ZKqPWLfErn3eFXsMpncYxyPu3Uzp51WFEdoTJ
BhbptiaicarUbEua7PiWAWEMo5p9lfUavssHcAbShWxI0rGof7/3PwlzKdlmjbv1
2Xc68INUB1l4EBgnVbZtFeX8YqFScw==
=FVEu
-----END PGP SIGNATURE-----

--eKLqXSuhsjfwfQXk--