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, 31 Mar 2022 13:34:22 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Martin =?utf-8?Q?Povi=C5=A1er?= <povik+lin@cutebit.org>
Cc:     Liam Girdwood <lgirdwood@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzk+dt@kernel.org>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>, alsa-devel@alsa-project.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        Mark Kettenis <kettenis@openbsd.org>,
        Hector Martin <marcan@marcan.st>,
        Sven Peter <sven@svenpeter.dev>
Subject: Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver
Message-ID: <YkWfziQzprEsWL72@sirena.org.uk>
References: <20220331000449.41062-1-povik+lin@cutebit.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="3w0XWtrOW4Hfhq/l"
Content-Disposition: inline
In-Reply-To: <20220331000449.41062-1-povik+lin@cutebit.org>
Precedence: bulk


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

On Thu, Mar 31, 2022 at 02:04:44AM +0200, Martin Povi=C5=A1er wrote:

> I put together a machine-level ASoC driver for recent Apple Macs (the
> ones with ARM64 SoCs) and want to gauge opinions.

This would be a bit easier to review with a description of the hardware.

> Commit 2 adds a new ASoC card method (filter_controls) to let the card
> prevent some codec kcontrols from being visible to userspace. For example
> the TAS2770 speaker amp driver would be happy to expose TDM slot selection
> and ISENSE/VSENSE enables which is ridiculous. I am all ears on how to
> make the patch acceptable to upstream.

The broad issue here is that what you consider ridiculous someone else
might have some bright ideas for configuring dynamically - if things are
being exposed for dynamic configuration it's probably because someone
wanted them, if the control is genuinely useless then it should just be
removed.  Rather than getting in the way of people's policy arguments
about how to set things we expose them to userspace and let userspace
worry about it, usually with the help of UCM files.  The general
userspace model is that people interact with their sound server more
than the hardware card.  This is also helpful for people developing use
cases, it means they're not having to get the kernel rebuilt to tune
things.

The TDM swap thing you're mentioning looks like it's a left/right
selection which people do use sometimes as a way of doing mono mixes and
reorientation.  The ISENSE/VSENSE is less obvious, though it's possible
there's issues with not having enough slots on a heavily used TDM bus or
sometimes disabling the speaker protection processing for whatever
reason.

--3w0XWtrOW4Hfhq/l
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmJFn80ACgkQJNaLcl1U
h9AgOggAhaQ6MuCNl7L/md1tarO7n6iReHCzBcOCtSc6T8vIiDTatsSdqb4mHmkZ
jeeF4LCTvo+tb01vzCqHVStd4Pz5dMRv+3F8lI6ODG3g16Tv+E1CKQeIGkVM6VJN
IwzoRsgTtDkz0h0Qi/6t0P4hSu/sobPGHwV8KYBGi4RjuuNl62tQzyUJOYmYah18
Xaz6IbrYmtSc8zgq8tytUxG1j3HRO1icmWWM9jkpqMtGD+CESPbAJV2yWZUTywtl
VjJf6JjiiXmMrAZLY0PlRZON2ePlsyARsJFPy9TDrhaErq2rSLhPI+FMaL6dssH2
YOHlHOpxBEp1DEl5HsKaxiDhyA2x4A==
=BnTH
-----END PGP SIGNATURE-----

--3w0XWtrOW4Hfhq/l--