Re: [v4 13/18] ASoC: mediatek: mt8186: add platform driver

[Jiaxin Yu <jiaxin.yu@mediatek.com>]

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@mediatek.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