From: Herve Codina <herve.codina@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
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
Date: Wed, 26 Apr 2023 09:36:21 +0200 [thread overview]
Message-ID: <20230426093621.3834e703@bootlin.com> (raw)
In-Reply-To: <20230425173029.GA1967523-robh@kernel.org>
Hi Rob,
On Tue, 25 Apr 2023 12:30:29 -0500
Rob Herring <robh@kernel.org> wrote:
> 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. :)
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.
>
> Examples of devices would be useful here.
>
> >
> > Signed-off-by: Herve Codina <herve.codina@bootlin.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@bootlin.com>
> > +
> > +description: |
>
> Don't need '|'
Will be fixed.
>
> > + Auxiliary device based on Industrial I/O device channels
> > +
> > +allOf:
> > + - $ref: /schemas/iio/iio-consumer.yaml
>
> You don't need to reference consumer schemas.
Right, will be removed.
>
> > + - $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.
What do you mean ?
>
> > + $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?
As Mark said, for IIO channel, using CHx makes sense.
See below, I provide a full example.
>
> > + /* Invert CH1 and CH2 */
> > + invert = <0 1 1>;
>
> IMO, invert should be same length as io-channels.
I will update.
Related to this topic, when I wrote this binding, I wanted to add some
rules/constraints in order to:
- Have this property optional
- If present, force to have as many items in the invert array as the
number of items present in the io-channels array.
I never succeed in writing the constraint for the invert property.
It should be possible (it is done for some 'foo' 'foo-names' pair such
as clocks).
Can you tell me if possible in my case and give me some pointers ?
>
> > + };
>
> 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.
I don't see what you mean.
I use a simple-audio-card and here is a full example using several
instances:
spi {
#address-cells = <1>;
#size-cells = <0>;
/* potentiometers present in an input amplifier design */
pot_in: potentiometer@0 {
compatible = "foo,xxx";
reg = <0>;
#io-channel-cells = <1>;
};
/* potentiometers present in an output amplifier design */
pot_out: potentiometer@1 {
compatible = "foo,xxx";
reg = <1>;
#io-channel-cells = <1>;
};
/* A codec */
codec: codec@2 {
compatible = "bar,yyy";
reg = <2>;
sound-name-prefix = "CODEC";
};
};
amp_out: aux-out {
compatible = "simple-iio-aux";
io-channels = <&pot_out 0>, <&pot_out 1>,
io-channel-names = "CH0", "CH1";
invert = <1 1>;
sound-name-prefix = "AMP_OUT";
};
amp_in: aux-in {
compatible = "simple-iio-aux";
io-channels = <&pot_in 0>, <&pot_in 1>;
io-channel-names = "CH0", "CH1";
sound-name-prefix = "AMP_IN";
};
sound {
compatible = "simple-audio-card";
#address-cells = <1>;
#size-cells = <0>;
simple-audio-card,name = "My Sound Card";
simple-audio-card,aux-devs = <&_in>, <&_out>;
simple-audio-card,routing =
"CODEC IN0", "AMP_IN CH0 OUT",
"CODEC IN1", "AMP_IN CH1 OUT",
"AMP_OUT CH0 IN", "CODEC OUT0",
"AMP_OUT CH1 IN", "CODEC OUT1",
simple-audio-card,dai-link@0 {
...
};
};
Best regards,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2023-04-26 7:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 12:41 [PATCH 0/4] Add support for IIO devices in ASoC Herve Codina
2023-04-21 12:41 ` [PATCH 1/4] dt-bindings: sound: Add simple-iio-aux Herve Codina
2023-04-25 17:30 ` Rob Herring
2023-04-25 17:33 ` Mark Brown
2023-04-26 7:36 ` Herve Codina [this message]
2023-05-02 7:26 ` Krzysztof Kozlowski
2023-05-04 4:22 ` Mark Brown
2023-05-11 7:19 ` Herve Codina
2023-04-21 12:41 ` [PATCH 2/4] iio: inkern: Add a helper to query an available minimum raw value Herve Codina
2023-04-22 16:49 ` Jonathan Cameron
2023-04-24 7:50 ` Herve Codina
2023-05-01 15:15 ` Jonathan Cameron
2023-04-21 12:41 ` [PATCH 3/4] ASoC: soc-dapm.h: Add a helper to build a DAPM widget dynamically Herve Codina
2023-04-21 12:41 ` [PATCH 4/4] ASoC: codecs: Add support for the generic IIO auxiliary devices Herve Codina
2023-04-22 17:08 ` Jonathan Cameron
2023-04-24 10:52 ` Herve Codina
2023-05-01 15:24 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230426093621.3834e703@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=robh@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).