Received: by 10.223.185.116 with SMTP id b49csp6041554wrg; Wed, 28 Feb 2018 03:02:04 -0800 (PST) X-Google-Smtp-Source: AH8x2271lVg8JbQdRFS/b/8wlJsSTGb2QnUVkyue075HH+yB/awZsq3rwbaeyU7IGJiWr5Jo9tV+ X-Received: by 10.98.224.65 with SMTP id f62mr17367027pfh.191.1519815724228; Wed, 28 Feb 2018 03:02:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519815724; cv=none; d=google.com; s=arc-20160816; b=oGraTg25MrWNFQBrBc6eaZLWd7eYZQOdQrsxYYcgGGOoOreHr6eEzBodAkfyG171Yg iAkeOgq3E4cCcYG0FSP07hnLy5pjmWgRXW5rZAQumkydhYJwoQHPti/1n/T810KbILRw ikhRu8UDwfaRNXhZKVGN7REaEd0/BxSG8l4qz4aAGhzJMhlR1OoO2nxdvcoDgp7XUnFt JYYQ92qpvGMYD+ZSaHqSSY447uBLVXbBuatiL/TtNrLr4I9Lnt6bZk42rH/bmqHx/g0H GUkpVwwmu9X/i/kPCM8OsvWbEjP3NwI/ff2Ik/KULrVGo8Le7/ihIVqoXZcITFwjYMDk v+nA== 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:arc-authentication-results; bh=P3FPHhDBZexSE0FXo/W5VCIUXyGdTxALZ45IfeGr+Jc=; b=Ouhd42rg5lxfOLah90kAD7VvFi4y6VCB27A0AjvpdA3bvBERoIJYd+WIJV1B9mQGgN TEpgJw7RViSTYEGMCC+iXnZDPflvjoIlPzc5y9muk93bnGPGsQYfFJbjiHbN8rMFl6Wa 3f5BRsEZQJ86DzuLTVlrr0HR2GcACHKXeWMmBWuuh4Gg8tId1EHqjf9go4dX08FDNAul Vs2RBG6Id2/KkTmGgXb8TehhJ/0+EkPgYCbl2LTKwYvLlan/jmXvimBX1QqGV1FTm+H2 ra9yFjMeO+leKZXtJD4xlES6l3dNEX1HJMCM1cp42hdUwDKdgJnuivPmk/swjXJPPAyX pXZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=u1Q5J2Mn; 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 s12si833435pgq.491.2018.02.28.03.01.44; Wed, 28 Feb 2018 03:02:04 -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; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=u1Q5J2Mn; 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 S1752283AbeB1LAz (ORCPT + 99 others); Wed, 28 Feb 2018 06:00:55 -0500 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:57606 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752155AbeB1LAw (ORCPT ); Wed, 28 Feb 2018 06:00:52 -0500 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=P3FPHhDBZexSE0FXo/W5VCIUXyGdTxALZ45IfeGr+Jc=; b=u1Q5J2MnTIqUbERK7+K/lURPR IJj1R+5Di29tv4nnzB/btbps33hQ1bAtMC/aXxokWk+Zl2KMNQZoCRpm721r14rMuDtE1OaPCXpJ2 fdqMAU90+9m/gQRMufames1TgoKz72XKkPWGGWZc2p2FtkEVlAlXR1dfjhR41faxuhgeM=; Received: from debutante.sirena.org.uk ([2001:470:1f1d:6b5::3] helo=debutante) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1eqzTT-0001rn-R5; Wed, 28 Feb 2018 11:00:39 +0000 Received: from broonie by debutante with local (Exim 4.90_1) (envelope-from ) id 1eqzTS-0004ab-DL; Wed, 28 Feb 2018 11:00:38 +0000 Date: Wed, 28 Feb 2018 11:00:38 +0000 From: Mark Brown To: Matt Porter Cc: Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Rob Herring , Mark Rutland , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ASoC: add tda7419 audio processor driver Message-ID: <20180228110038.GA6722@sirena.org.uk> References: <20180227225128.17815-1-mporter@konsulko.com> <20180227225128.17815-3-mporter@konsulko.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <20180227225128.17815-3-mporter@konsulko.com> X-Cookie: TANSTAAFL User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 27, 2018 at 05:51:28PM -0500, Matt Porter wrote: > +static bool tda7419_writeable_reg(struct device *dev, unsigned int reg) > +{ > + return true; > +} This is the default behaviour, may as well omit it (but equally it does no harm). > +static inline int tda7419_vol_get_value(int val, unsigned int mask, > + int thresh, unsigned int invert) > +{ > + val &= mask; > + if (val < thresh) { > + if (invert) > + val = 0 - val; > + } else if (val > thresh) { This feels like something some other device might want to use so might warrant pulling out into a general control at some point but I'd not insist on doing it now. > +static struct snd_kcontrol_new tda7419_controls[] = { > +SOC_ENUM("Main Source Select", soc_enum_main_src_sel), Should this be a DAPM route? > +SOC_SINGLE("Main Source AutoZero", TDA7419_MAIN_SRC_REG, > + TDA7419_MAIN_SRC_AUTOZERO, 1, 1), There's a lot of on/off switches for various things in here - these should all have Switch at the end of their names so that userspace can see how it's expected to display them. Most of the controls with a max value of 1 probably fall into this category. > +SOC_SINGLE("Clock Fast Mode", TDA7419_MUTE_CLK_REG, > + TDA7419_CLK_FAST_MODE, 1, 1), What does this do - should it be in set_sysclk() or something? > + /* Configure registers */ > + regmap_write(tda7419->regmap, TDA7419_VOLUME_REG, 0xe0); > + regmap_write(tda7419->regmap, TDA7419_MIXING_GAIN_REG, 0x0f); > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LF_REG, 0xe0); > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RF_REG, 0xe0); > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LR_REG, 0xe0); > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RR_REG, 0xe0); > + regmap_write(tda7419->regmap, TDA7419_MIXING_LEVEL_REG, 0xe0); > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_SUB_REG, 0xe0); This looks like it's setting default volumes - just leave those at the chip defaults and let userspace handle setting them, what works for one board may be totally inappropriate on another board and using the chip default means we've got some fixed thing we don't need to discuss. > +static int tda7419_remove(struct i2c_client *i2c) > +{ > + int i; > + struct tda7419_data *tda7419 = i2c_get_clientdata(i2c); > + > + /* Reset registers to defaults */ > + for (i = 0; i < ARRAY_SIZE(tda7419_regmap_defaults); i++) > + regmap_write(tda7419->regmap, > + tda7419_regmap_defaults[i].reg, > + tda7419_regmap_defaults[i].def); Why are we doing this? Other drivers don't do it... if anything I'd expect a reset on probe in case the bootloader or something left the chip configured. --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlqWi9UACgkQJNaLcl1U h9BvNAf+Kt7wqrYcDAbhkitQVbfFcMWKs9ptkQUJ7gUfe51CTL3LXCUKMaERhR6r sU9mECFOm/0cDskE6XyuVDwcvh3IaWyeJ3rM0DoV97DtDQpYBvpuzk5ISBZMlp71 igzd+rGERaO1u5Hx7nEYJBWdcMUAdJcCeXuQmQPwUY9nTux1YlyCTR+OwpnM+VC9 lzcB5hJDCQ/Aig0l8d/200magEc/VKG3GA//5yUYjw71pSnt2SEHdScldzMQTL1m xASe/cFZtONv3S/SzLBffyJovPTdIWtJVlGvvZfmv2S22b/hqFfEqELHLZC+eHIZ YibWqZ27mK7kjkYMzLHUno04OkIF2A== =7vZJ -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn--