Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4910045ybl; Mon, 13 Jan 2020 23:46:28 -0800 (PST) X-Google-Smtp-Source: APXvYqxffyoUGUXlxxjvjIWWpA+SYvktJTIouaNLfUcCTd2g2pqv7pRYObfWJTklSFEEgyHVh4tk X-Received: by 2002:a05:6808:312:: with SMTP id i18mr16126842oie.44.1578987988495; Mon, 13 Jan 2020 23:46:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578987988; cv=none; d=google.com; s=arc-20160816; b=q4XQkyFCcld8zYn2C1B2Tpdoe1EojdgPVNGkPjaW3ftTLJt5cm7akTIcbGcJ+2DZt0 dW7JIaO/SIZhoKxxSVGDxnF7IvY5nchUx8KIzo123KI2/dDSB9ppZT9MbdGLHuMiQ8NP hjouvexPCq5Np3ycbWHooaNIXzJdVwfcG8kCS/rCOrYnKKS48DZUlALujF4z5Gk+5loL yp9snvH89/esoodHdZQmb8ymlk7fZh680b0tULjeql2cOZhCoa3/OdooRarotKuKbt75 4685tMgaNQj/A6TrpvAUa7q/2AdJSLKBqJ3WCTtnNSoFA9sxUPV1+w5XIr3xGZfkwubQ dkIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=xVEEe8yZGRNBOGQfv9lMC5TNyKCiR+P4+ZXxrQp9zZk=; b=Iwc+nlMG/b3BT3/tSmwh8GMco9n01cbslX+ziS1Gs2fZMJKGS5GOKY/rW0q+2itgPa UngTrioGtF9QrgDIdMoWKt3qruyNhMnExsh9gOhcxZ6WmXa8xnS3kWpJZqNYlTBTc63+ 5zuKdhZ7RUj567nw+A9QaalRHq3GcaK9xaLmQ0A7iaeZa0KcQYjDGFnDGkdIlblXZhSZ r+2i9Jq1gKZ9qIMrwwyTAAgf+x7qAW9hT6h6DBtT2PkYwDuD7AQgGn1maOsTFmy9hmWT VUe+j31nrztqkpcuBQNC9LkKkBgg0K3Hle/HT2v5H/8QDu54XO1sSkwPCDQiBV8lzt88 j1Vg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f89si994781otf.231.2020.01.13.23.46.04; Mon, 13 Jan 2020 23:46:28 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729033AbgANHo0 (ORCPT + 99 others); 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