[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230425173029.GA1967523-robh@kernel.org>
Date: Tue, 25 Apr 2023 12:30:29 -0500
From: Rob Herring <robh@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Jonathan Cameron <jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-iio@...r.kernel.org,
Christophe Leroy <christophe.leroy@...roup.eu>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 1/4] dt-bindings: sound: Add simple-iio-aux
On Fri, Apr 21, 2023 at 02:41:19PM +0200, Herve Codina wrote:
> Industrial I/O devices can be present in the audio path.
> These devices needs to be viewed as audio components in order to be
> fully integrated in the audio path.
>
> simple-iio-aux allows to consider these Industrial I/O devices as
> auxliary audio devices.
What makes it simple? Any binding called simple or generic is a trigger
for me. Best to avoid those terms. :)
Examples of devices would be useful here.
>
> Signed-off-by: Herve Codina <herve.codina@...tlin.com>
> ---
> .../bindings/sound/simple-iio-aux.yaml | 65 +++++++++++++++++++
> 1 file changed, 65 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/simple-iio-aux.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/simple-iio-aux.yaml b/Documentation/devicetree/bindings/sound/simple-iio-aux.yaml
> new file mode 100644
> index 000000000000..fab128fce4fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/simple-iio-aux.yaml
> @@ -0,0 +1,65 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/simple-iio-aux.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple IIO auxiliary
> +
> +maintainers:
> + - Herve Codina <herve.codina@...tlin.com>
> +
> +description: |
Don't need '|'
> + Auxiliary device based on Industrial I/O device channels
> +
> +allOf:
> + - $ref: /schemas/iio/iio-consumer.yaml
You don't need to reference consumer schemas.
> + - $ref: dai-common.yaml#
> +
> +properties:
> + compatible:
> + const: simple-iio-aux
> +
> + io-channels:
> + description:
> + Industrial I/O device channels used
> +
> + io-channel-names:
> + description:
> + Industrial I/O channel names related to io-channels.
> + These names are used to provides sound controls, widgets and routes names.
> +
> + invert:
Property names should globally only have 1 type definition. This is
generic enough I'd be concerned that's not the case.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + A list of 0/1 flags defining whether or not the related channel is
> + inverted
> + items:
> + enum: [0, 1]
> + default: 0
> + description: |
> + Invert the sound control value compared to the IIO channel raw value.
> + - 1: The related sound control value is inverted meaning that the
> + minimum sound control value correspond to the maximum IIO channel
> + raw value and the maximum sound control value correspond to the
> + minimum IIO channel raw value.
> + - 0: The related sound control value is not inverted meaning that the
> + minimum (resp maximum) sound control value correspond to the
> + minimum (resp maximum) IIO channel raw value.
> +
> +required:
> + - compatible
> + - io-channels
> + - io-channel-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + aux {
> + compatible = "simple-iio-aux";
> + io-channels = <&iio 0>, <&iio 1>, <&iio 2>, <&iio 3>;
> + io-channel-names = "CH0", "CH1", "CH2", "CH3";
Not really useful names. Do you have a real example?
> + /* Invert CH1 and CH2 */
> + invert = <0 1 1>;
IMO, invert should be same length as io-channels.
> + };
How do support multiple instances? Say you have 2 sound cards (or 1
sound card with multiple audio paths) each with different sets of IIO
channels associated with it. You'd need a link to each 'aux' node. 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.
Rob
Powered by blists - more mailing lists