Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 12 Aug 2020 13:05:37 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Jiaxin Yu <jiaxin.yu@mediatek.com>
Cc:     matthias.bgg@gmail.com, robh+dt@kernel.org, tiwai@suse.com,
        linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org, howie.huang@mediatek.com,
        tzungbi@google.com, eason.yen@mediatek.com,
        shane.chien@mediatek.com
Subject: Re: [PATCH v2 1/2] ASoC: mediatek: mt6359: add codec driver
Message-ID: <20200812120537.GA5545@sirena.org.uk>
References: <1597028754-7732-1-git-send-email-jiaxin.yu@mediatek.com>
 <1597028754-7732-2-git-send-email-jiaxin.yu@mediatek.com>
 <20200810185933.GI6438@sirena.org.uk>
 <1597217353.23246.45.camel@mhfsdcap03>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
In-Reply-To: <1597217353.23246.45.camel@mhfsdcap03>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 12, 2020 at 03:29:13PM +0800, Jiaxin Yu wrote:
> On Mon, 2020-08-10 at 19:59 +0100, Mark Brown wrote:
> > On Mon, Aug 10, 2020 at 11:05:53AM +0800, Jiaxin Yu wrote:

> > > +void mt6359_set_playback_gpio(struct snd_soc_component *cmpnt)
> > > +{
> > > +	struct mt6359_priv *priv =3D snd_soc_component_get_drvdata(cmpnt);

> > What are these, should they not be managed through gpiolib and/or
> > pinctrl?

> These are the functions that control the mux of input or output
> signal. I refer to the other codec drivers, most of them are manipulate
> the regs in their codec drivers also. Maybe it's easier to control?

These functions are exported for other drivers to use rather than
something done internally by the driver - if this were internal to the
driver it'd not be a big deal but when it's for use by another driver
it'd be better to go through standard interfaces.

> > > +int mt6359_mtkaif_calibration_enable(struct snd_soc_pcm_runtime *rtd)
> > > +{

> > > +EXPORT_SYMBOL_GPL(mt6359_mtkaif_calibration_enable);

> > Why is this exported?

> This function is exported to machine driver to do calibration when
> registering. The interface between MT6359 and MTK SoC is a special
> interface that named MTKAIF. Therefore, if MT6359 is to be used
> normally, it needs to rely on the platform for calibration when
> registering.

So this needs the SoC to do something as part of callibration?

> > > +	switch (event) {
> > > +	case SND_SOC_DAPM_PRE_PMU:
> > > +		priv->dev_counter[device]++;
> > > +		if (priv->dev_counter[device] > 1)
> > > +			break;	/* already enabled, do nothing */
> > > +		else if (priv->dev_counter[device] <=3D 0)

> > Why are we doing additional refcounting on top of what DAPM is doing?
> > This seems like there should be at least one widget representing the
> > shared bits of the audio path.

> We have "HPL Mux" and "HPR Mux", there will be two paths enabled when
> playback throuh HP. But actually they share the same control sequences.
> So in order to prevent setting it one more time we do additional
> refcouting.

That sounds like you should just have one output path defined in DAPM
and merge the left and right signals together rather than maintaining
them separately.

> > > +	/* hp gain ctl default choose ZCD */
> > > +	priv->hp_gain_ctl =3D HP_GAIN_CTL_ZCD;
> > > +	hp_gain_ctl_select(priv, priv->hp_gain_ctl);

> > Why not use the hardware default?

> We have two ways to control the volume, there is to select ZCD. Because
> the other one it not often used, ZCD is used by default.=20

Why not just let the user pick at runtime?

> > > +	ret =3D regulator_enable(priv->avdd_reg);
> > > +	if (ret) {
> > > +		dev_err(priv->dev, "%s(), failed to enable regulator!\n",
> > > +			__func__);
> > > +		return ret;
> > > +	}

> > Perhaps make this a DAPM widget?

> "vaud18" needs to be always on so we enable it when codec probe.

If it is just supposed to be left on all the time it's better to do this
in the main device model probe rather than the component probe.  The
component probe should usually only be used for things that need the
rest of the card to be there.

--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl8z2xAACgkQJNaLcl1U
h9D7Wwf+OdwVBUD42cfqMOKbAwel1jObAQofx/ASxy8YgjsPQp8Jjkm39G6YSYyJ
8nK3lQ1sz6qZtJ2KsZp6jG/aEOC5w7aBQdZszyRHXuneIp4KtvLG+AYHSO54DMXb
ftsOw4EyQjzNY61qz0ZZ3H7vMObW+1o8uMEBKadB8MMz7oufbCUcV8auAps+K+L1
si165INgJFZpfrKk/8YvNVqBAlcXMDjGpcZtO6gfEi9AuDQnZfJWte/1hOBgQynL
84UFJWIEtkVCWadlYwBU1VcQD/3bOkpfyFMIoYII0BquCKBUqxmcLA2NxFV7Ami1
U58UVe1qf4mt+vS7hAjBlmh6JTrUnw==
=Fkwb
-----END PGP SIGNATURE-----

--yrj/dFKFPuw6o+aM--