Document dmic_sel-gpios optional prop for switching between two DMICs.
Ex, the GPIO can control a MUX to select Front or Rear dmic.

Signed-off-by: Ajye Huang <ajye_huang@compal.corp-partner.google.com>
---
 Documentation/devicetree/bindings/sound/dmic-codec.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/dmic-codec.yaml b/Documentation/devicetree/bindings/sound/dmic-codec.yaml
index bba27c985996..4013af65f3e7 100644
--- a/Documentation/devicetree/bindings/sound/dmic-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/dmic-codec.yaml
@@ -36,6 +36,10 @@ properties:
   wakeup-delay-ms:
     description: Delay (in ms) after enabling the DMIC
 
+  dmic_sel-gpios:
+    maxItems: 1
+    description: GPIO for switching between DMICs, ex Front/Rear dmic
+
 required:
   - compatible
 
@@ -48,6 +52,7 @@ examples:
     dmic {
         compatible = "dmic-codec";
         dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>;
+        dmic_sel-gpios = <&pio 23 GPIO_ACTIVE_HIGH>;
         num-channels = <1>;
         wakeup-delay-ms = <50>;
         modeswitch-delay-ms = <35>;
-- 
2.25.1

On Fri, Oct 28, 2022 at 06:24:49PM +0800, Ajye Huang wrote:
> Document dmic_sel-gpios optional prop for switching between two DMICs.
> Ex, the GPIO can control a MUX to select Front or Rear dmic.

> +  dmic_sel-gpios:
> +    maxItems: 1
> +    description: GPIO for switching between DMICs, ex Front/Rear dmic
> +

If we're going to do this we should also allow the bindings to label the
mics appropriately so that the control presented can reflect the actual
hardware.  It does feel like it might fit better to do this separately
to the DMIC driver as a mux between the DMIC and the DAI it's connected
to but equally with the way things are at the minute that feels like
it's probably disproportionate effort.

On Fri, Oct 28, 2022 at 12:56:16PM +0100, Mark Brown wrote:
> On Fri, Oct 28, 2022 at 06:24:49PM +0800, Ajye Huang wrote:
> > Document dmic_sel-gpios optional prop for switching between two DMICs.
> > Ex, the GPIO can control a MUX to select Front or Rear dmic.
> 
> > +  dmic_sel-gpios:

s/_/-/

> > +    maxItems: 1
> > +    description: GPIO for switching between DMICs, ex Front/Rear dmic
> > +
> 
> If we're going to do this we should also allow the bindings to label the
> mics appropriately so that the control presented can reflect the actual
> hardware.  It does feel like it might fit better to do this separately
> to the DMIC driver as a mux between the DMIC and the DAI it's connected
> to but equally with the way things are at the minute that feels like
> it's probably disproportionate effort.

Are there other needs for DAI muxes? We already have a mux binding, so 
defining a DAI mux would work for any type of muxing control, not just 
GPIO.

Rob

On Mon, Oct 31, 2022 at 01:43:43PM -0500, Rob Herring wrote:
> On Fri, Oct 28, 2022 at 12:56:16PM +0100, Mark Brown wrote:

> > If we're going to do this we should also allow the bindings to label the
> > mics appropriately so that the control presented can reflect the actual
> > hardware.  It does feel like it might fit better to do this separately
> > to the DMIC driver as a mux between the DMIC and the DAI it's connected
> > to but equally with the way things are at the minute that feels like
> > it's probably disproportionate effort.

> Are there other needs for DAI muxes? We already have a mux binding, so 
> defining a DAI mux would work for any type of muxing control, not just 
> GPIO.

I suspect that anything that is more complex than a GPIO should be a
full fledged CODEC with the muxing internal to the CODEC and just
described that way.

Hi Mark, Rob

To avoid confusion, I had submitted another one for process

Hi Mark, Rob

I submitted another one to process the kcontrol in the audio machine
driver instead,  sorry about that previous non-completed mail.
 https://patchwork.kernel.org/project/alsa-devel/patch/20221031122224.1846221-2-ajye_huang@compal.corp-partner.google.com/
thanks

On Tue, Nov 1, 2022 at 9:04 AM Ajye Huang
<ajye_huang@compal.corp-partner.google.com> wrote:
>
> Hi Mark, Rob
>
> To avoid confusion, I had submitted another one for process