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:   Thu, 4 May 2023 13:22:35 +0900
From:   Mark Brown <broonie@kernel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Herve Codina <herve.codina@bootlin.com>,
        Rob Herring <robh@kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Jonathan Cameron <jic23@kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>, alsa-devel@alsa-project.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-iio@vger.kernel.org,
        Christophe Leroy <christophe.leroy@csgroup.eu>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 1/4] dt-bindings: sound: Add simple-iio-aux
Message-ID: <ZFMzC7OBrcL9l5AH@finisterre.sirena.org.uk>
References: <20230421124122.324820-1-herve.codina@bootlin.com>
 <20230421124122.324820-2-herve.codina@bootlin.com>
 <20230425173029.GA1967523-robh@kernel.org>
 <20230426093621.3834e703@bootlin.com>
 <5bcb2741-9212-f1aa-335b-6bc4b6fad448@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="gAqgDYGpNO6m8hZu"
Content-Disposition: inline
In-Reply-To: <5bcb2741-9212-f1aa-335b-6bc4b6fad448@linaro.org>
Precedence: bulk


--gAqgDYGpNO6m8hZu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 02, 2023 at 09:26:32AM +0200, Krzysztof Kozlowski wrote:
> On 26/04/2023 09:36, Herve Codina wrote:
> > Rob Herring <robh@kernel.org> wrote:
> >> On Fri, Apr 21, 2023 at 02:41:19PM +0200, Herve Codina wrote:

> >>> simple-iio-aux allows to consider these Industrial I/O devices as
> >>> auxliary audio devices. =20

> >> What makes it simple? Any binding called simple or generic is a trigge=
r=20
> >> for me. Best to avoid those terms. :)

> > I choose simple-iio-aux because some simple-* already exists.
> > For instance simple-audio-amplifier or simple-audio-mux.

> > Do you prefer audio-iio-aux ?
> > Let me know if I should change.

> It means that often what people call "simple" and "generic" works only
> for their specific case, because it is not really simple and generic.
> After some time the "simple" and "generic" becomes "complicated" and
> "huge". Conclusion: sometimes simple and generic bindings are bad idea
> and you should have something specific.

> Your description in the binding also does not help to match it to
> specific, real device. Provide the examples, as Rob asked.

I don't understand what you are looking for here.  IIO is a subsystem
which represents generic DACs and ADCs (along with other I/O things).
Audio devices also have DACs and ADCs, somewhat specialised for use in
audio but more limited by specs and interfaces than by anything
fundamental.  The goal here is to map DACs and ADCs described as IIO for
use in an audio context.

ADCs are devices that convert analog signals into digital values, DACs
are devices that convert digital values into analog signals.

> >> How do support multiple instances? Say you have 2 sound cards (or 1=20
> >> sound card with multiple audio paths) each with different sets of IIO=
=20
> >> channels associated with it. You'd need a link to each 'aux' node. Why=
=20
> >> not just add io-channels to the sound card nodes directly? That's=20
> >> already just a virtual, top-level container node grouping all the=20
> >> components. I don't see why we need another virtual node grouping a=20
> >> subset of them.

> > I don't see what you mean.
> > I use a simple-audio-card and here is a full example using several
> > instances:

> Just like Rob said: "You'd need a link to each 'aux' node"

> and you did it...

> So now the rest of Rob's answer:

> "Why not just add io-channels to the sound card nodes directly? That's
> already just a virtual, top-level container node grouping all the
> components. I don't see why we need another virtual node grouping a
> subset of them."

> Why do you need another node if it is not really representing a real,
> separate device?

If nothing else I would expect it to be useful from a comprehensibility
point of view to bundle multiple IIO devices into a single multi-channel
audio stream, an individual IIO device is likely to only present a
single channel of data but it is common to group multiple channels of
audio data.

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

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmRTMwkACgkQJNaLcl1U
h9CpIgf8DGHa33KFaEBu9orPEvy62t4yb0j+p3Xoar2zISlY832/jm9hk/8oYSdy
etd75hsgD7l1/K6l08YwHxuJX07geLoyEnyUakiEi+w4rZVBJ8z/Vj+XN2lV6eq8
VJwUq+kvpY63mjLQodrOLSH9ixNk24ab28aU5CWrw9qUPKfTSLIJLoh9ZkH081eL
nBl+himFtVaWSmQ4+6l9lDNy4VJianGJ6cQI/66k9H0/LMIvj/HGo4DFbCSGzIRu
ZXukxdcZCuH8mI9jHPglgmvaYkjyaAmEW3/89b8F/0lOtOpsoDWjAqWhMJhcphhH
XjquUq/o3sVr1uXMMKdl3fmfUnNhDQ==
=PI/4
-----END PGP SIGNATURE-----

--gAqgDYGpNO6m8hZu--