Message-ID: <CAFv8NwL1xX=yPGFqQL_mOzAnPTfH0Z0J6ibG1+D32W46Nx0KYQ@mail.gmail.com>
Date:   Tue, 20 Oct 2020 21:37:05 +0800
From:   Cheng-yi Chiang <cychiang@...omium.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Taniya Das <tdas@...eaurora.org>,
        Rohit kumar <rohitkr@...eaurora.org>,
        Banajit Goswami <bgoswami@...eaurora.org>,
        Patrick Lai <plai@...eaurora.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Stephan Gerhold <stephan@...hold.net>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Srinivasa Rao <srivasam@...eaurora.org>,
        Doug Anderson <dianders@...omium.org>,
        Dylan Reid <dgreid@...omium.org>,
        Tzung-Bi Shih <tzungbi@...omium.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." 
        <alsa-devel@...a-project.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Ajye Huang <ajye_huang@...pal.corp-partner.google.com>
Subject: Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings

On Fri, Oct 16, 2020 at 12:13 AM Mark Brown <broonie@...nel.org> wrote:
>
> On Thu, Oct 15, 2020 at 03:59:26PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Oct 13, 2020 at 6:36 PM Srinivas Kandagatla
>
> > > > +properties:
> > > > +  compatible:
> > > > +    const: qcom,sc7180-sndcard-rt5682-m98357-1mic
>
> > > This information can come from the dai link description itself, why
> > > should compatible string have this information?
>
> > I think dailink description is not enough to specify everything
> > machine driver needs to know.
> > E.g. there is a variation where there are front mic and rear mic. We
> > need to tell the machine driver about it so
> > it can create proper widget, route, and controls.
>
> That sounds like something that could be better described with
> properties (including for example the existing bindings used for setting
> up things like analogue outputs and DAPM routes)?
>

Hi Mark, thank you for the comments.

May I know your suggestion on Ajye's patch "ASoC: qcom: sc7180: Modify
machine driver for 2mic" ?

https://lore.kernel.org/r/20200928063744.525700-3-ajye_huang@compal.corp-partner.google.com

I think adding code in the machine driver makes the intent straightforward.
If we want the machine driver to be fully configurable,
we can always add more code to handle properties like gpio, route,
widget (mux, text selection) passed in from the device tree.
But I feel that we don't need a machine driver to be that configurable
from the device tree.
I think having the logic scattered in various dtsi files and relying
on manual inspection to understand the usage would be less
maintainable than only exposing needed property like gpio.
Especially in the complicated case where we need to create a mux
widget with callback toggling the gpio like this:

+static const char * const dmic_mux_text[] = {
+       "Front Mic",
+       "Rear Mic",
+};
+
+static SOC_ENUM_SINGLE_DECL(sc7180_dmic_enum,
+                           SND_SOC_NOPM, 0, dmic_mux_text);
+
+static const struct snd_kcontrol_new sc7180_dmic_mux_control =
+       SOC_DAPM_ENUM_EXT("DMIC Select Mux", sc7180_dmic_enum,
+                         dmic_get, dmic_set);
+
+SND_SOC_DAPM_MUX("Dmic Mux", SND_SOC_NOPM, 0, 0, &sc7180_dmic_mux_control),

Passing all the logic along with the callback of dmic_get, dmic_set
from the device tree would be too hard to maintain.

> > The codec combination also matters. There will be a variation where
> > rt5682 is replaced with adau7002 for dmic.
> > Although machine driver can derive some information by looking at dailink,
> > I think specifying it explicitly in the compatible string is easier to
> > tell what machine driver should do, e.g.
> > setting PLL related to rt5682 or not.
>
> These feel more like things that fit with compatible, though please take
> a look at Morimoto-san's (CCed) work on generic sound cards for more
> complex devices:
>
>    https://lore.kernel.org/alsa-devel/87imbeybq5.wl-kuninori.morimoto.gx@renesas.com/
>
> This is not yet implemented but it'd be good to make sure that the
> Qualcomm systems can be handled too in future.

Yes, that should work to describe the dailink we are using.
But a more tricky issue is how to do calls like setting PLL in dai startup ops.

                /* Configure PLL1 for codec */
                ret = snd_soc_dai_set_pll(codec_dai, 0, RT5682_PLL1_S_MCLK,
                                          DEFAULT_MCLK_RATE, RT5682_PLL1_FREQ);

I think that asking a generic machine driver to do configuration like
this with only a limited interface of device property
might be too much of an ask for the machine driver.

>
> > You can see widget, route, controls are used according to the configuration.
> > The alternative approach is to check whether "dmic-gpio" property
> > exists to decide adding these stuff or not.
> > But it makes the intent less easier to understand.
>
> OTOH if you have lots of compatibles then it can get hard to work out
> exactly which one corresponds to a given board.

Totally agree. Glad we have only three variations up to now.

Would you mind if I simplify the compatible string like Srinivas
suggested, and send a v12?

As for other two kinds of variations that I am aware of:

1. front mic / rear mic
2. replace alc5682 with adau7002

We can set different board names and different compatible strings to
achieve such variation.
So that it would make sense to describe configuration in compatible
strings like you suggested, and also provides UCM a way to distinguish
different boards.
What do you think ?

Thanks!

Powered by blists - more mailing lists