Message ID | 20220428093355.16172-1-jiaxin.yu@mediatek.com |
---|---|
Headers | show |
Series | ASoC: mediatek: Add support for MT8186 SoC | expand |
On Fri, 2022-04-29 at 10:47 +0200, Geert Uytterhoeven wrote: > Hi Jiaxin, > > Gmail tends to mark your patches as spam. > Can you please make sure to use "PATCH" in the subject line, e.g. > "[PATCH v4 00/18] ASoC: mediatek: Add support for MT8186 SoC"? > > Thanks! > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- > geert@linux-m68k.org > > In personal conversations with technical people, I call myself a > hacker. But > when I'm talking to journalists I just say "programmer" or something > like that. > -- Linus Torvalds Hi Geert, Sorry for this mistake, I usually use "git format-patch --subject- prefix "v4" --cover-letter -x" to generate a series of patches. So it automatically removes "PATCH". I will correct the cmd to "git format-patch --subject-prefix "PATCH v4" --cover-letter -x". Thanks, Jiaxin.Yu
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