Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2227218ybe; Tue, 3 Sep 2019 09:40:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqyhPdM8YQiWgizL4qtX7hj69pDgPUGNNCiF88BXtjShkYHVXmDS1X1gfzarPv1bEEOg+qdr X-Received: by 2002:aa7:85c2:: with SMTP id z2mr10138049pfn.205.1567528813332; Tue, 03 Sep 2019 09:40:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567528813; cv=none; d=google.com; s=arc-20160816; b=QmJIIEF/jtFD5FpdJH6qGySBpgXKJpaoP82YT825Bl2BQMRpqQJUR+3/4iULasE7sw HwDAw8AInhdZCMAj/p7nPgJXz1X69KCd5hU1eTSAuvKwcEUG0AtmZxWNDmbpMCf9ejMP CqLobzfVcWUUZhwtvkvUs2APiBMhsYJzC2L3Q3h7b5TUiuXyojxQngFw8yV6XXYHOCV/ f+xj1PMTA6KqLVH2i9WKYZQp8G+FR8ykRa8hq79YPCk7Y2YrVCHbu/VfuCyUAXvNclHO hpqMtbOKkdNOLPvXtgwgUlRsL+hkBkd2BreX1ofJjZ9tjQyGaHGaxOFDc5z6OQLZ5wsy Ku7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=SJ8sp8FvDRuyze29OLcsHkJ1fO3LZuMK56azmXlvfRM=; b=GX8xgSsFzkumUCoQCleCYbxaJ+pIlRQUQSGzxJa2R+i8LKNH5xSYgESkj1MO839hF2 1YIf59yigbBpVMJy/Axs7EEThCGyZcWeUl0ECKx7A7KBJjC/aozDAy5ySBmdXgdcI0dW 0qi2aF/Syp60UJ8SKTE2ZuCzZoKdEYvVZme5fSV4kQtNfzAOGyNg3r6KG9eyrw5Dzox+ /ODIWkMuE1rBr9pi13UuLVJxjkGjPfQ7tMqwNQpd1cJSKbL0Gz+UHf7VmIbvrGaNdFEz 5fWan/MqQocQMF5hZhk9RWKG1OUucXKzeUmCrQ60RI5C6iu3mt8von9a2wY55OHDSL4X s/+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=APOdbs66; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c20si13260794pfr.118.2019.09.03.09.39.56; Tue, 03 Sep 2019 09:40:13 -0700 (PDT) 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; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=APOdbs66; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731361AbfICQjI (ORCPT + 99 others); Tue, 3 Sep 2019 12:39:08 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:45334 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730650AbfICQjH (ORCPT ); Tue, 3 Sep 2019 12:39:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SJ8sp8FvDRuyze29OLcsHkJ1fO3LZuMK56azmXlvfRM=; b=APOdbs66SGlqWMxcn+FKIVqGD tpbvxPtv+sFs7ndBggj7ezK7Mrix3mSgR/vgyiXmz5V5wCSEnj9fAuriGJY0xtnxbG/nbbMAPIoBZ OS5/sm/FO0LZp0EflXUnHsjTqHjyK3+V6ExMsM0RClrjcL3uRHOucUulOjdhVNPklxobo=; Received: from ypsilon.sirena.org.uk ([2001:470:1f1d:6b5::7]) by heliosphere.sirena.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1i5Bp8-0000lg-QW; Tue, 03 Sep 2019 16:38:30 +0000 Received: by ypsilon.sirena.org.uk (Postfix, from userid 1000) id 5A9D62740A95; Tue, 3 Sep 2019 17:38:29 +0100 (BST) Date: Tue, 3 Sep 2019 17:38:29 +0100 From: Mark Brown To: richtek.jeff.chang@gmail.com Cc: lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com, matthias.bgg@gmail.com, alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [MT6660] Mediatek Smart Amplifier Driver Message-ID: <20190903163829.GB7916@sirena.co.uk> References: <1567494501-3427-1-git-send-email-richtek.jeff.chang@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline In-Reply-To: <1567494501-3427-1-git-send-email-richtek.jeff.chang@gmail.com> X-Cookie: You will pass away very quickly. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 03, 2019 at 03:08:21PM +0800, richtek.jeff.chang@gmail.com wrote: > --- /dev/null > +++ b/sound/soc/codecs/mt6660.c > @@ -0,0 +1,802 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 MediaTek Inc. > + */ Please make the entire comment block a C++ comment so things look more consistent. > +struct reg_size_table { > + u32 addr; > + u8 size; > +}; > +static const struct reg_size_table mt6660_reg_size_table[] = { > + { MT6660_REG_HPF1_COEF, 4 }, > + { MT6660_REG_HPF2_COEF, 4 }, > + { MT6660_REG_TDM_CFG3, 2 }, > + { MT6660_REG_RESV17, 2 }, > + { MT6660_REG_RESV23, 2 }, > + { MT6660_REG_SIGMAX, 2 }, > + { MT6660_REG_DEVID, 2}, > + { MT6660_REG_TDM_CFG3, 2}, > + { MT6660_REG_HCLIP_CTRL, 2}, > + { MT6660_REG_DA_GAIN, 2}, > +}; Please talk to your hardware designers about the benefits of consistent register sizes :/ > +static int32_t mt6660_i2c_update_bits(struct mt6660_chip *chip, > + uint32_t addr, uint32_t mask, uint32_t data) > +{ It would be good to implement a regmap rather than open coding *everything* - it'd give you things like this without needing to open code them. Providing you don't use the cache code it should cope fine with variable register sizes. > + > +static int mt6660_i2c_init_setting(struct mt6660_chip *chip) > +{ > + int i, len, ret; > + const struct codec_reg_val *init_table; > + > + init_table = e4_reg_inits; > + len = ARRAY_SIZE(e4_reg_inits); > + > + for (i = 0; i < len; i++) { > + ret = mt6660_i2c_update_bits(chip, init_table[i].addr, > + init_table[i].mask, init_table[i].data); > + if (ret < 0) > + return ret; Why are we not using the chip defaults here? > +static int mt6660_chip_power_on( > + struct snd_soc_component *component, int on_off) > +{ > + struct mt6660_chip *chip = (struct mt6660_chip *) > + snd_soc_component_get_drvdata(component); > + int ret = 0; > + unsigned int val; > + > + dev_dbg(component->dev, "%s: on_off = %d\n", __func__, on_off); > + mutex_lock(&chip->var_lock); > + if (on_off) { > + if (chip->pwr_cnt == 0) { > + ret = mt6660_i2c_update_bits(chip, > + MT6660_REG_SYSTEM_CTRL, 0x01, 0x00); > + val = mt6660_i2c_read(chip, MT6660_REG_IRQ_STATUS1); > + dev_info(chip->dev, > + "%s reg0x05 = 0x%x\n", __func__, val); > + } > + chip->pwr_cnt++; This looks like you're open coding runtime PM stuff? AFAICT the issue is that you need to write to this register to do any I/O. Just implement this via the standard runtime PM framework, you'll need to do something about the register I/O in the controls (ideally in the framework, it'd be a lot easier if you did have a cache) but you could cut out this bit. > +static int mt6660_component_set_bias_level(struct snd_soc_component *component, > + enum snd_soc_bias_level level) > +{ > + struct snd_soc_dapm_context *dapm = > + snd_soc_component_get_dapm(component); > + int ret; > + unsigned int val; > + struct mt6660_chip *chip = snd_soc_component_get_drvdata(component); > + > + if (dapm->bias_level == level) { > + dev_warn(component->dev, "%s: repeat level change\n", __func__); This shouldn't be a warning. > +static const struct snd_kcontrol_new mt6660_component_snd_controls[] = { > + SOC_SINGLE_EXT_TLV("Volume_Ctrl", MT6660_REG_VOL_CTRL, 0, 255, > + 1, snd_soc_get_volsw, mt6660_component_put_volsw, > + vol_ctl_tlv), > + SOC_SINGLE_EXT("WDT_Enable", MT6660_REG_WDT_CTRL, 7, 1, 0, > + snd_soc_get_volsw, mt6660_component_put_volsw), These control names should all use standard ALSA control names - on/off switches should end in Switch, volume controls in Volume. > + SOC_SINGLE_EXT("I2SLRS", MT6660_REG_DATAO_SEL, 6, 3, 0, > + snd_soc_get_volsw, mt6660_component_put_volsw), > + SOC_SINGLE_EXT("I2SDOLS", MT6660_REG_DATAO_SEL, 3, 7, 0, > + snd_soc_get_volsw, mt6660_component_put_volsw), > + SOC_SINGLE_EXT("I2SDORS", MT6660_REG_DATAO_SEL, 0, 7, 0, > + snd_soc_get_volsw, mt6660_component_put_volsw), What do these controls do? --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl1ulwQACgkQJNaLcl1U h9DsxAf8DiH9juppC2atx8j+pwupdXbxOIeEil91IOqQMEBBSSJ1oa1nPDIz1HkH yJY7jq4QIijIkqA0b5Op3zEXSHIve3j3ZoUnN/Wrj6ODeyzrDXSvsDm/gB2/G3xJ AQYMGCGEaL3i0OmnFBf3LKCqG/FceKjOmg7QqcuNMGqLkdHdwiNMguc+5QkuSamM dvb3ZKnicrimjhMSocpe38qRFfcld4gJp6psfeDIQ8z2A1V8dtiNNrAbza/ArDUB kfUE1VkdWMTs1kOrjrTZl067ZzOTLBbSiulfxzDtM1UjB3LSteshyCkoVI5K+QBW qJJLfLqnH76e09UCIYvXbbV1J/oeRw== =1Pf1 -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB--