From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C967EC33CB1 for ; Tue, 14 Jan 2020 10:14:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A2B1A207FF for ; Tue, 14 Jan 2020 10:14:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728951AbgANKOT (ORCPT ); Tue, 14 Jan 2020 05:14:19 -0500 Received: from mx2.suse.de ([195.135.220.15]:58458 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733130AbgANKM4 (ORCPT ); Tue, 14 Jan 2020 05:12:56 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 80D61ADEB; Tue, 14 Jan 2020 10:12:54 +0000 (UTC) Date: Tue, 14 Jan 2020 11:12:53 +0100 Message-ID: From: Takashi Iwai To: jeff_chang (=?UTF-8?B?5by15LiW5L2z?=) Cc: Jeff Chang , "lgirdwood@gmail.com" , "broonie@kernel.org" , "perex@perex.cz" , "tiwai@suse.com" , "matthias.bgg@gmail.com" , "alsa-devel@alsa-project.org" , "linux-arm-kernel@lists.infradead.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> <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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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