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=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,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 AAF00C33CB1 for ; Tue, 14 Jan 2020 07:44:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 864A3206D7 for ; Tue, 14 Jan 2020 07:44:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729072AbgANHo0 (ORCPT ); Tue, 14 Jan 2020 02:44:26 -0500 Received: from mx2.suse.de ([195.135.220.15]:36752 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728801AbgANHo0 (ORCPT ); Tue, 14 Jan 2020 02:44:26 -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 9B5D4AC6E; Tue, 14 Jan 2020 07:44:23 +0000 (UTC) Date: Tue, 14 Jan 2020 08:44:22 +0100 Message-ID: From: Takashi Iwai To: Jeff Chang Cc: 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, jeff_chang@richtek.com Subject: Re: [PATCH v6] ASoC: Add MediaTek MT6660 Speaker Amp Driver In-Reply-To: <1578968526-13191-1-git-send-email-richtek.jeff.chang@gmail.com> References: <1578968526-13191-1-git-send-email-richtek.jeff.chang@gmail.com> 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=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 14 Jan 2020 03:22:06 +0100, Jeff Chang wrote: > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > index 229cc89..f135fbb 100644 > --- a/sound/soc/codecs/Kconfig > +++ b/sound/soc/codecs/Kconfig > @@ -1465,6 +1466,16 @@ config SND_SOC_MT6358 > Enable support for the platform which uses MT6358 as > external codec device. > > +config SND_SOC_MT6660 > + tristate "Mediatek MT6660 Speaker Amplifier" > + depends on I2C > + help > + MediaTek MT6660 is a smart power amplifier which contain > + speaker protection, multi-band DRC, equalizer functions. > + Select N if you don't have MT6660 on board. > + Select M to build this as module. > + > + One blank line too much here. > --- /dev/null > +++ b/sound/soc/codecs/mt6660.c > @@ -0,0 +1,533 @@ > +// SPDX-License-Identifier: GPL-2.0 // > + > +// Copyright (c) 2019 MediaTek Inc. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Move linux/*.h above sound/*.h inclusion. > + > +#include "mt6660.h" > + > +#pragma pack(push, 1) Actually packing makes little sense for those use cases. As I mentioned earlier, packing is useful only for either saving some memory (e.g. for a large array) or a strict size definition like ABI. > +struct codec_reg_val { > + u32 addr; > + u32 mask; > + u32 data; > +}; Is this struct used anywhere? If not, kill it. > +static struct regmap_config mt6660_regmap_config = { This can be const. > +static int mt6660_codec_dac_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + A superfluous blank line. > +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? > +static int _mt6660_chip_power_on(struct mt6660_chip *chip, int on_off) > +{ > + u8 reg_data; > + int ret; > + > + ret = i2c_smbus_read_byte_data(chip->i2c, MT6660_REG_SYSTEM_CTRL); > + if (ret < 0) > + return ret; > + reg_data = (u8)ret; > + if (on_off) > + reg_data &= (~0x01); > + else > + reg_data |= 0x01; > + return regmap_write(chip->regmap, MT6660_REG_SYSTEM_CTRL, reg_data); Hm, this looks like an open-code of forced update bits via regmap. But interestingly there is no corresponding standard helper for that. Essentially it should be regmap_update_bits_base() with force=1. Mark? > +static int mt6660_component_aif_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *hw_params, struct snd_soc_dai *dai) > +{ > + int word_len = params_physical_width(hw_params); > + int aud_bit = params_width(hw_params); .... > + switch (aud_bit) { > + case 16: > + reg_data = 3; > + break; > + case 18: > + reg_data = 2; > + break; > + case 20: > + reg_data = 1; > + break; > + case 24: > + case 32: > + reg_data = 0; > + break; 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? > +static inline int _mt6660_chip_id_check(struct mt6660_chip *chip) Drop unnecessary inline (here and other places). Compiler optimizes well by itself. > +static inline int _mt6660_chip_sw_reset(struct mt6660_chip *chip) > +{ > + int ret; > + > + /* turn on main pll first, then trigger reset */ > + ret = regmap_write(chip->regmap, 0x03, 0x00); It's MT6660_REG_SYSTEM_CTRL, right? > + if (ret < 0) > + return ret; > + ret = regmap_write(chip->regmap, MT6660_REG_SYSTEM_CTRL, 0x80); > + if (ret < 0) > + return ret; > + msleep(30); > + return 0; > +} > + > +static inline int _mt6660_read_chip_revision(struct mt6660_chip *chip) > +{ > + u8 reg_data[2]; > + int ret; > + > + ret = i2c_smbus_read_i2c_block_data( > + chip->i2c, MT6660_REG_DEVID, 2, reg_data); Why avoiding regmap here? This and chip_id_check() use the raw access by some reason... thanks, Takashi 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=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,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 22951C33CB1 for ; Tue, 14 Jan 2020 13:25:21 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A63AE24658 for ; Tue, 14 Jan 2020 13:25:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A63AE24658 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (unknown [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 2CFC32D17; Tue, 14 Jan 2020 08:44:34 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 2CFC32D17 Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 48917F8014D; Tue, 14 Jan 2020 08:44:33 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 1938BF8014E; Tue, 14 Jan 2020 08:44:30 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 67120F800E9 for ; Tue, 14 Jan 2020 08:44:24 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 67120F800E9 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 9B5D4AC6E; Tue, 14 Jan 2020 07:44:23 +0000 (UTC) Date: Tue, 14 Jan 2020 08:44:22 +0100 Message-ID: From: Takashi Iwai To: Jeff Chang In-Reply-To: <1578968526-13191-1-git-send-email-richtek.jeff.chang@gmail.com> References: <1578968526-13191-1-git-send-email-richtek.jeff.chang@gmail.com> 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") Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, tiwai@suse.com, lgirdwood@gmail.com, jeff_chang@richtek.com, broonie@kernel.org, matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [alsa-devel] [PATCH v6] ASoC: Add MediaTek MT6660 Speaker Amp Driver X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, 14 Jan 2020 03:22:06 +0100, Jeff Chang wrote: > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > index 229cc89..f135fbb 100644 > --- a/sound/soc/codecs/Kconfig > +++ b/sound/soc/codecs/Kconfig > @@ -1465,6 +1466,16 @@ config SND_SOC_MT6358 > Enable support for the platform which uses MT6358 as > external codec device. > > +config SND_SOC_MT6660 > + tristate "Mediatek MT6660 Speaker Amplifier" > + depends on I2C > + help > + MediaTek MT6660 is a smart power amplifier which contain > + speaker protection, multi-band DRC, equalizer functions. > + Select N if you don't have MT6660 on board. > + Select M to build this as module. > + > + One blank line too much here. > --- /dev/null > +++ b/sound/soc/codecs/mt6660.c > @@ -0,0 +1,533 @@ > +// SPDX-License-Identifier: GPL-2.0 // > + > +// Copyright (c) 2019 MediaTek Inc. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Move linux/*.h above sound/*.h inclusion. > + > +#include "mt6660.h" > + > +#pragma pack(push, 1) Actually packing makes little sense for those use cases. As I mentioned earlier, packing is useful only for either saving some memory (e.g. for a large array) or a strict size definition like ABI. > +struct codec_reg_val { > + u32 addr; > + u32 mask; > + u32 data; > +}; Is this struct used anywhere? If not, kill it. > +static struct regmap_config mt6660_regmap_config = { This can be const. > +static int mt6660_codec_dac_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + A superfluous blank line. > +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? > +static int _mt6660_chip_power_on(struct mt6660_chip *chip, int on_off) > +{ > + u8 reg_data; > + int ret; > + > + ret = i2c_smbus_read_byte_data(chip->i2c, MT6660_REG_SYSTEM_CTRL); > + if (ret < 0) > + return ret; > + reg_data = (u8)ret; > + if (on_off) > + reg_data &= (~0x01); > + else > + reg_data |= 0x01; > + return regmap_write(chip->regmap, MT6660_REG_SYSTEM_CTRL, reg_data); Hm, this looks like an open-code of forced update bits via regmap. But interestingly there is no corresponding standard helper for that. Essentially it should be regmap_update_bits_base() with force=1. Mark? > +static int mt6660_component_aif_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *hw_params, struct snd_soc_dai *dai) > +{ > + int word_len = params_physical_width(hw_params); > + int aud_bit = params_width(hw_params); .... > + switch (aud_bit) { > + case 16: > + reg_data = 3; > + break; > + case 18: > + reg_data = 2; > + break; > + case 20: > + reg_data = 1; > + break; > + case 24: > + case 32: > + reg_data = 0; > + break; 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? > +static inline int _mt6660_chip_id_check(struct mt6660_chip *chip) Drop unnecessary inline (here and other places). Compiler optimizes well by itself. > +static inline int _mt6660_chip_sw_reset(struct mt6660_chip *chip) > +{ > + int ret; > + > + /* turn on main pll first, then trigger reset */ > + ret = regmap_write(chip->regmap, 0x03, 0x00); It's MT6660_REG_SYSTEM_CTRL, right? > + if (ret < 0) > + return ret; > + ret = regmap_write(chip->regmap, MT6660_REG_SYSTEM_CTRL, 0x80); > + if (ret < 0) > + return ret; > + msleep(30); > + return 0; > +} > + > +static inline int _mt6660_read_chip_revision(struct mt6660_chip *chip) > +{ > + u8 reg_data[2]; > + int ret; > + > + ret = i2c_smbus_read_i2c_block_data( > + chip->i2c, MT6660_REG_DEVID, 2, reg_data); Why avoiding regmap here? This and chip_id_check() use the raw access by some reason... thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel 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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 B0AA6C33CB1 for ; Tue, 14 Jan 2020 07:44:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 83F23206D7 for ; Tue, 14 Jan 2020 07:44:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OkepMJOD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83F23206D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ms1wFMHIFU002T1Nd1pFr5u/Yw02CHgQ3cynmpK3Q+I=; b=OkepMJODtjB0q5 YkW82AxZQhPuYZQNxXtn4P2jM8ykDUtKMNJQHNpc285ZvVRu7C1ybQNZfC8c2dXfJC/x9ciESh9zm UuCUFdzkos28CcT98RpaOipR4bTqfW61yxQYanGTWJMRONWhbe4jy+HEygclk+KLLfgtPuYLOFM3J Uiypg7L87SI8c05jWGuxGWaEoiZWdu4NycPZzliybf1kvm8PFcKdK6lpcrx0JXW8lIW3mfFkk1ILk dikTqHlmqljrtoD9UoIDXBdnRPsbNl5NIDjwLlUJIdSWfjacuoVRlq4Nw3J0QLm1redItl1dhddHo D03nDdknCCLZfccU7JRA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1irGsO-0001Fm-5E; Tue, 14 Jan 2020 07:44:36 +0000 Received: from mx2.suse.de ([195.135.220.15]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1irGsJ-0001EH-Lo for linux-arm-kernel@lists.infradead.org; Tue, 14 Jan 2020 07:44:33 +0000 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 9B5D4AC6E; Tue, 14 Jan 2020 07:44:23 +0000 (UTC) Date: Tue, 14 Jan 2020 08:44:22 +0100 Message-ID: From: Takashi Iwai To: Jeff Chang Subject: Re: [PATCH v6] ASoC: Add MediaTek MT6660 Speaker Amp Driver In-Reply-To: <1578968526-13191-1-git-send-email-richtek.jeff.chang@gmail.com> References: <1578968526-13191-1-git-send-email-richtek.jeff.chang@gmail.com> 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") X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200113_234432_007522_0DA99B22 X-CRM114-Status: GOOD ( 19.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, tiwai@suse.com, lgirdwood@gmail.com, jeff_chang@richtek.com, broonie@kernel.org, matthias.bgg@gmail.com, perex@perex.cz, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 14 Jan 2020 03:22:06 +0100, Jeff Chang wrote: > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig > index 229cc89..f135fbb 100644 > --- a/sound/soc/codecs/Kconfig > +++ b/sound/soc/codecs/Kconfig > @@ -1465,6 +1466,16 @@ config SND_SOC_MT6358 > Enable support for the platform which uses MT6358 as > external codec device. > > +config SND_SOC_MT6660 > + tristate "Mediatek MT6660 Speaker Amplifier" > + depends on I2C > + help > + MediaTek MT6660 is a smart power amplifier which contain > + speaker protection, multi-band DRC, equalizer functions. > + Select N if you don't have MT6660 on board. > + Select M to build this as module. > + > + One blank line too much here. > --- /dev/null > +++ b/sound/soc/codecs/mt6660.c > @@ -0,0 +1,533 @@ > +// SPDX-License-Identifier: GPL-2.0 // > + > +// Copyright (c) 2019 MediaTek Inc. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Move linux/*.h above sound/*.h inclusion. > + > +#include "mt6660.h" > + > +#pragma pack(push, 1) Actually packing makes little sense for those use cases. As I mentioned earlier, packing is useful only for either saving some memory (e.g. for a large array) or a strict size definition like ABI. > +struct codec_reg_val { > + u32 addr; > + u32 mask; > + u32 data; > +}; Is this struct used anywhere? If not, kill it. > +static struct regmap_config mt6660_regmap_config = { This can be const. > +static int mt6660_codec_dac_event(struct snd_soc_dapm_widget *w, > + struct snd_kcontrol *kcontrol, int event) > +{ > + A superfluous blank line. > +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? > +static int _mt6660_chip_power_on(struct mt6660_chip *chip, int on_off) > +{ > + u8 reg_data; > + int ret; > + > + ret = i2c_smbus_read_byte_data(chip->i2c, MT6660_REG_SYSTEM_CTRL); > + if (ret < 0) > + return ret; > + reg_data = (u8)ret; > + if (on_off) > + reg_data &= (~0x01); > + else > + reg_data |= 0x01; > + return regmap_write(chip->regmap, MT6660_REG_SYSTEM_CTRL, reg_data); Hm, this looks like an open-code of forced update bits via regmap. But interestingly there is no corresponding standard helper for that. Essentially it should be regmap_update_bits_base() with force=1. Mark? > +static int mt6660_component_aif_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *hw_params, struct snd_soc_dai *dai) > +{ > + int word_len = params_physical_width(hw_params); > + int aud_bit = params_width(hw_params); .... > + switch (aud_bit) { > + case 16: > + reg_data = 3; > + break; > + case 18: > + reg_data = 2; > + break; > + case 20: > + reg_data = 1; > + break; > + case 24: > + case 32: > + reg_data = 0; > + break; 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? > +static inline int _mt6660_chip_id_check(struct mt6660_chip *chip) Drop unnecessary inline (here and other places). Compiler optimizes well by itself. > +static inline int _mt6660_chip_sw_reset(struct mt6660_chip *chip) > +{ > + int ret; > + > + /* turn on main pll first, then trigger reset */ > + ret = regmap_write(chip->regmap, 0x03, 0x00); It's MT6660_REG_SYSTEM_CTRL, right? > + if (ret < 0) > + return ret; > + ret = regmap_write(chip->regmap, MT6660_REG_SYSTEM_CTRL, 0x80); > + if (ret < 0) > + return ret; > + msleep(30); > + return 0; > +} > + > +static inline int _mt6660_read_chip_revision(struct mt6660_chip *chip) > +{ > + u8 reg_data[2]; > + int ret; > + > + ret = i2c_smbus_read_i2c_block_data( > + chip->i2c, MT6660_REG_DEVID, 2, reg_data); Why avoiding regmap here? This and chip_id_check() use the raw access by some reason... thanks, Takashi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel