Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 14 Jan 2020 11:12:53 +0100
Message-ID: <s5hwo9uqrbu.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     jeff_chang (=?UTF-8?B?5by15LiW5L2z?=) <jeff_chang@richtek.com>
Cc:     Jeff Chang <richtek.jeff.chang@gmail.com>,
        "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "perex@perex.cz" <perex@perex.cz>,
        "tiwai@suse.com" <tiwai@suse.com>,
        "matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6] ASoC: Add MediaTek MT6660 Speaker Amp Driver
In-Reply-To: <36357249c6ed4a989cd11535fdefef6e@ex1.rt.l>
References: <1578968526-13191-1-git-send-email-richtek.jeff.chang@gmail.com>
        <s5htv4yfpnt.wl-tiwai@suse.de>
        <36357249c6ed4a989cd11535fdefef6e@ex1.rt.l>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 14 Jan 2020 10:48:24 +0100,
jeff_chang(張世佳) wrote:
> 
> Dear Takashi:
> 
> Thank for your replying.
> 
> 1.> +static int mt6660_component_get_volsw(struct snd_kcontrol *kcontrol,
> > +  struct snd_ctl_elem_value *ucontrol) {
> > +struct snd_soc_component *component =
> > +snd_soc_kcontrol_component(kcontrol);
> > +struct mt6660_chip *chip = (struct mt6660_chip *)
> > +snd_soc_component_get_drvdata(component);
> > +int ret = -EINVAL;
> > +
> > +if (!strcmp(kcontrol->id.name, "Chip Rev")) {
> > +ucontrol->value.integer.value[0] = chip->chip_rev & 0x0f;
> > +ret = 0;
> > +}
> > +return ret;
> 
> So, "T0 SEL" control gets always an error when reading?
> Then can't we pass simply NULL for get ops instead?
> 
> Jeff : T0 SEL use snd_soc_get_volsw, it will not use this function.

Then what's the reason of this hackish check?


> 2. So here both 24 and 32 bits data are handled equally, and...
> 
> ....
> > +ret = snd_soc_component_update_bits(dai->component,
> > +MT6660_REG_TDM_CFG3, 0x3f0, word_len << 4);
> 
> ... word_len is same for both S32 and S24 formats, so there can be no difference between S24 and S32 format handling in the code.
> Meanwhile, the supported formats are:
> 
> > +#define STUB_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | \
> > +SNDRV_PCM_FMTBIT_U16_LE | \
> > +SNDRV_PCM_FMTBIT_S24_LE | \
> > +SNDRV_PCM_FMTBIT_U24_LE | \
> > +SNDRV_PCM_FMTBIT_S32_LE | \
> > +SNDRV_PCM_FMTBIT_U32_LE)
> 
> Are you sure that S24_* formats really work properly?
> 
> Also, the code has no check / setup of the format signedness.
> Do unsigned formats (U16, U24, etc) really work as expected, too?
> 
> 
> Jeff :  Yes, it works.

So, for the codec, it doesn't matter at all about the signedness and
the alingment of 32bit / 24bit of the incoming signals, but magically
handled as is?  Interesting...


thanks,

Takashi