Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032839AbbKFIP5 (ORCPT ); Fri, 6 Nov 2015 03:15:57 -0500 Received: from regular1.263xmail.com ([211.150.99.137]:43345 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032433AbbKFIPz (ORCPT ); Fri, 6 Nov 2015 03:15:55 -0500 X-263anti-spam: KSV:0;BIG:0;ABS:1;DNS:0;ATT:0;SPF:S; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 1 X-SKE-CHECKED: 1 X-ADDR-CHECKED: 0 X-RL-SENDER: zhengsq@rock-chips.com X-FST-TO: linux-rockchip@lists.infradead.org X-SENDER-IP: 43.226.228.153 X-LOGIN-NAME: zhengsq@rock-chips.com X-UNIQUE-TAG: <5fdf53db1e1b67288200347dceeec9d5> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <563C61A9.2080105@rock-chips.com> Date: Fri, 06 Nov 2015 16:15:37 +0800 From: Shunqian Zheng Reply-To: zhengsq@rock-chips.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Mark Brown CC: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, heiko@sntech.de, lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com, benzh@chromium.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org Subject: Re: [PATCH v2 1/2] ASoC: codec: Inno codec driver for RK3036 SoC References: <1446717194-8572-1-git-send-email-zhengsq@rock-chips.com> <1446717194-8572-2-git-send-email-zhengsq@rock-chips.com> <20151105161311.GR18409@sirena.org.uk> In-Reply-To: <20151105161311.GR18409@sirena.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2691 Lines: 71 Mark, On 2015年11月06日 00:13, Mark Brown wrote: > On Thu, Nov 05, 2015 at 05:53:13PM +0800, Shunqian Zheng wrote: > > This is basically all good, a few very minor comments below but nothing > that should take any time to fix. > >> +static const char *rk3036_codec_antipop_text[] = {"none", "work"}; >> +static const unsigned int rk3036_codec_antipop_values[] = {0x1, 0x2}; >> + >> +static SOC_VALUE_ENUM_DOUBLE_DECL(rk3036_codec_antipop_enum, INNO_R09, >> + INNO_R09_HPL_ANITPOP_SHIFT, INNO_R09_HPR_ANITPOP_SHIFT, 0x3, >> + rk3036_codec_antipop_text, rk3036_codec_antipop_values); > This looks like a simple boolean control rather than an enum - it looks > like it's just turning antipop on and off. It is a boolean control, but it takes 2 bits -- the value of "on" is b10 and b01 for "off". So I try to use VALUE_ENUM. > >> + SOC_DOUBLE_R_RANGE_TLV("Headphone Volume", INNO_R07, INNO_R08, >> + INNO_HP_GAIN_SHIFT, INNO_HP_GAIN_N39DB, >> + INNO_HP_GAIN_0DB, 0, rk3036_codec_hp_tlv), >> + SOC_DOUBLE("Zero Cross Detect", INNO_R06, INNO_R06_VOUTL_CZ_SHIFT, >> + INNO_R06_VOUTR_CZ_SHIFT, 1, 0), > This should be "Zero Cross Switch". Make change in V3. > >> + SOC_DOUBLE("HP Mute", INNO_R09, INNO_R09_HPL_MUTE_SHIFT, >> + INNO_R09_HPR_MUTE_SHIFT, 1, 1), > This should be "Headphone Switch". Make change in V3. > >> +static int rk3036_codec_add_widgets(struct snd_soc_codec *codec) >> +{ >> + struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec); >> + >> + snd_soc_add_codec_controls(codec, rk3036_codec_dapm_controls, >> + ARRAY_SIZE(rk3036_codec_dapm_controls)); >> + >> + snd_soc_dapm_new_controls(dapm, rk3036_codec_dapm_widgets, >> + ARRAY_SIZE(rk3036_codec_dapm_widgets)); >> + >> + snd_soc_dapm_add_routes(dapm, rk3036_codec_dapm_routes, >> + ARRAY_SIZE(rk3036_codec_dapm_routes)); > Just point at the tables from the driver structure and let the core do > the initialisation for you. Make change in V3. > >> +static int rk3036_codec_set_bias_level(struct snd_soc_codec *codec, >> + enum snd_soc_bias_level level) >> +{ >> + switch (level) { >> + case SND_SOC_BIAS_STANDBY: >> + /* set a big current for capacitor charging. */ >> + snd_soc_write(codec, INNO_R10, INNO_R10_MAX_CUR); >> + /* start precharge */ >> + snd_soc_write(codec, INNO_R06, INNO_R06_DAC_PRECHARGE); > Do we not need to wait for this to ramp? The datasheet didn't give the delay value. It works in my tests. Thank you, Shunqian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/