[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99c329534a462b39d9b39ba04851318e7823e54c.camel@mediatek.com>
Date: Fri, 29 Apr 2022 18:07:52 +0800
From: Jiaxin Yu <jiaxin.yu@...iatek.com>
To: Mark Brown <broonie@...nel.org>
CC: <robh+dt@...nel.org>, <angelogioacchino.delregno@...labora.com>,
<aaronyu@...gle.com>, <matthias.bgg@...il.com>,
<trevor.wu@...iatek.com>, <tzungbi@...gle.com>,
<julianbraha@...il.com>, <alsa-devel@...a-project.org>,
<devicetree@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-mediatek@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>,
<Project_Global_Chrome_Upstream_Group@...iatek.com>
Subject: Re: [v4 13/18] ASoC: mediatek: mt8186: add platform driver
On Thu, 2022-04-28 at 13:02 +0100, Mark Brown wrote:
> On Thu, Apr 28, 2022 at 05:33:50PM +0800, Jiaxin Yu wrote:
> > Add mt8186 platform and affiliated driver.
> >
> > Signed-off-by: Jiaxin Yu <jiaxin.yu@...iatek.com>
> > ---
> > sound/soc/mediatek/Kconfig | 44 +
> > sound/soc/mediatek/Makefile | 1 +
> > sound/soc/mediatek/mt8186/Makefile | 22 +
> > sound/soc/mediatek/mt8186/mt8186-afe-common.h | 235 ++
> > .../soc/mediatek/mt8186/mt8186-afe-control.c | 261 ++
> > sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 3005
> > +++++++++++++++++
> > .../mediatek/mt8186/mt8186-interconnection.h | 69 +
> > .../soc/mediatek/mt8186/mt8186-misc-control.c | 294 ++
> > .../mediatek/mt8186/mt8186-mt6366-common.c | 59 +
> > .../mediatek/mt8186/mt8186-mt6366-common.h | 17 +
> > sound/soc/mediatek/mt8186/mt8186-reg.h | 2913
> > ++++++++++++++++
> > 11 files changed, 6920 insertions(+)
>
> This looks mostly good though it is enormous so I might've missed
> some
> things. The patch series is already very large but it might still be
> worth splitting this up a bit more, perhaps split the code and data
> tables/register definitions into separate patches?
>
Yes, agree with you.
I will spit them into three patches:
PATCH 1:
- mt8186-reg.h
- mt8186-interconnection.h
- mt8186-misc-control.c
PATCH 2:
- mt8186-mt6366-common.c
- mt8186-mt6366-common.h
PATCH 3:
- sound/soc/mediatek/Kconfig
- sound/soc/mediatek/Makefile
- sound/soc/mediatek/mt8186/Makefile
- sound/soc/mediatek/mt8186/mt8186-afe-common.h
- .../soc/mediatek/mt8186/mt8186-afe-control.c
- sound/soc/mediatek/mt8186/mt8186-afe-pcm.c
> A few relatively minor issues with the controls.
>
> > +/* this order must match reg bit amp_div_ch1/2 */
> > +static const char * const mt8186_sgen_amp_str[] = {
> > + "1/128", "1/64", "1/32", "1/16", "1/8", "1/4", "1/2", "1" };
> > +static const char * const mt8186_sgen_mute_str[] = {
> > + "Off", "On"
> > +};
>
> On/off controls should be normal Switch controls not enums so
> userspace
> can display things sensibly.
>
> > +static int mt8186_sgen_set(struct snd_kcontrol *kcontrol,
> > + struct snd_ctl_elem_value *ucontrol)
> > +{
> > + struct snd_soc_component *cmpnt =
> > snd_soc_kcontrol_component(kcontrol);
> > + struct mtk_base_afe *afe =
> > snd_soc_component_get_drvdata(cmpnt);
> > + struct mt8186_afe_private *afe_priv = afe->platform_priv;
> > + struct soc_enum *e = (struct soc_enum *)kcontrol-
> > >private_value;
> > + int mode;
> > + int mode_idx;
> > +
> > + if (ucontrol->value.enumerated.item[0] >= e->items)
> > + return -EINVAL;
>
> ...
>
> > + 0x3f << INNER_LOOP_BACK_MODE_SFT);
> > + }
> > +
> > + afe_priv->sgen_mode = mode;
> > +
> > + return 0;
> > +}
>
> This should return 1 if the value is different from the previous
> value
> so event generation works, please run mixer-test against a system
> using
> the driver to help spot issues like this. The same issue applies to
> at
> least some of the other custom controls.
>
Got it.
> > +static int mt8186_sgen_mute_set(struct snd_kcontrol *kcontrol,
> > + struct snd_ctl_elem_value *ucontrol)
> > +{
> > + struct snd_soc_component *cmpnt =
> > snd_soc_kcontrol_component(kcontrol);
> > + struct mtk_base_afe *afe =
> > snd_soc_component_get_drvdata(cmpnt);
> > + struct soc_enum *e = (struct soc_enum *)kcontrol-
> > >private_value;
> > + int mute;
> > +
> > + if (ucontrol->value.enumerated.item[0] >= e->items)
> > + return -EINVAL;
> > +
> > + mute = ucontrol->value.integer.value[0];
> > +
> > + dev_dbg(afe->dev, "%s(), kcontrol name %s, mute %d\n",
> > + __func__, kcontrol->id.name, mute);
> > +
> > + if (strcmp(kcontrol->id.name, SGEN_MUTE_CH1_KCONTROL_NAME) ==
> > 0) {
> > + regmap_update_bits(afe->regmap, AFE_SINEGEN_CON0,
> > + MUTE_SW_CH1_MASK_SFT,
> > + mute << MUTE_SW_CH1_SFT);
> > + } else {
> > + regmap_update_bits(afe->regmap, AFE_SINEGEN_CON0,
> > + MUTE_SW_CH2_MASK_SFT,
> > + mute << MUTE_SW_CH2_SFT);
> > + }
> > +
> > + return 0;
> > +}
>
> I can't tell why some of these are done with custom code rather than
> using a normal SOC_SINGLE()?
Yes, it's better to use SOC_SINGLE. I will fix them in next version.
Thanks,
Jiaxin.yu
Powered by blists - more mailing lists