Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp755919ybt; Wed, 8 Jul 2020 10:51:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqcO2ery4uipXpIALift+xmWFqWZ/bFGhAIm37KDlLnXG+//GIYTMNfJtN14ZygZv1ZzXB X-Received: by 2002:a17:906:191a:: with SMTP id a26mr54885223eje.315.1594230700466; Wed, 08 Jul 2020 10:51:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594230700; cv=none; d=google.com; s=arc-20160816; b=wOEm+CtluzcNG015c1u8m+WXGUYqI53NbpAHTXMDXZU26le+9m0Kw5G6B263xf5qI/ W8JRTUP5b8NIbD0IcxZXJY+oih0lYzOXTONBVnSVzzTE1JokhR6WF0nHaSgP0Q3PM0w1 N86koC4TXhsxr0IoNqdGawU92Y6myrR7GpI8X/Rw+kFsHg6RgSLtuy+XZVmgl4t/G0QZ bwd5dqRTF5nVzgO4NuHcr82DH9Cqsp4vb0RPmC2rhiWizGsCHD1MkFUyp0L5/3BnAZuz gM8EuajB+eIAzIKuZx5IUK3JoyWpwvH3Ye9tZdLJEUIdDVE/KP/pO7O1/MsPIlNAss1c xwPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=7SQJhbW9iFT0GAfAIqHssBvgsuF+/Q2rlb1LOfoE3Dg=; b=tyj8H0aWnlPY2jysrpchw8RfbLEY7hIUjTr/QC6vCkuLUSDpElhbDn82uF2afiLrkx tbqjkitAfru/hYurgaCznca7Kg0abyScA/FibIZB5FF7LQgI6eH78WeS8xo3GhwAiuzE qJQM3C5wzriCYVLCgWQ4O6o8yPM3Hs3uPEWibiVnCVqZwDOIEOzvbe21mxNDmEeIaV0S Ioibzh8nQW7Qm7q/M+NSOzsqPK0rkIA3KogXsf2E0dePie5VE+mifp/EZJKJq4ybclmo +KaaLxQzzOcXjX6k5/Liatp22j/B80jxiG3kzeSVRhlE2TZvgclpq+OZSmWfJSNS7Xo8 Qb2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=OzA7R+pv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a12si518399edf.4.2020.07.08.10.51.17; Wed, 08 Jul 2020 10:51:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=OzA7R+pv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726759AbgGHRvN (ORCPT + 99 others); Wed, 8 Jul 2020 13:51:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725937AbgGHRvM (ORCPT ); Wed, 8 Jul 2020 13:51:12 -0400 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90BC0C061A0B for ; Wed, 8 Jul 2020 10:51:12 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id z15so38622112wrl.8 for ; Wed, 08 Jul 2020 10:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7SQJhbW9iFT0GAfAIqHssBvgsuF+/Q2rlb1LOfoE3Dg=; b=OzA7R+pvW5s80iDwljKpzPfzJpi33QbPyL02J9vQRicBjee/2//LIsykAXKhMqcvfx 7rPtOGJEBnbi78A8LFqY0fQ2wG5o4Ekz8g18p+6qFlIXZZerwp76g2kRTc+rOfrd1m/0 Xl04VzboUPA0mE62FIpPY3fScjYQkYR8qTSy4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7SQJhbW9iFT0GAfAIqHssBvgsuF+/Q2rlb1LOfoE3Dg=; b=k33a/6EekkaMcy+RGbaMkgtOKjNe8X0K+o1No04tXP3C/aYMwXdVI8nXGO71R/rWI/ rfNfiMvCUM5qJdzR6GHtEC33FRaB8UtP9tv7iXVAqeq+UisB2obuvIlFpWKQ4ebFdkA5 WIxCtIri4cm1p6idbQw8rgqaZNViAqol79XxQMdMniX0FCq3K826D4FQllB/+6/BYnsM aaP036aKcPkm3xMWtGmVuzQ1CTV6kRBVNWph8bE+7TAHJ0gc2Q+18Cbcr7+i/nqlbTIK 2j61AXSR8nyzmAkULbDCPu0x+cGiyF8QzeqHT/K3aivNv0AXMFLiVO+RewzeckgmkKLs 2Tgg== X-Gm-Message-State: AOAM532yNxngl+jxEMdIT6k5g7XFKME25eehjMef5atr4GQahQjbmGw+ eHBYIZozbILRJj0VKPop6jlLa6/taFF7QaUlmvOo2A== X-Received: by 2002:adf:cf0a:: with SMTP id o10mr30713365wrj.14.1594230671246; Wed, 08 Jul 2020 10:51:11 -0700 (PDT) MIME-Version: 1.0 References: <20200708071117.3070707-1-yuhsuan@chromium.org> In-Reply-To: From: Yu-Hsuan Hsu Date: Thu, 9 Jul 2020 01:51:00 +0800 Message-ID: Subject: Re: [PATCH] ASoC: cros_ec_codec: Reset I2S RX when probing To: Guenter Roeck Cc: Enric Balletbo i Serra , linux-kernel , Benson Leung , Guenter Roeck , Cheng-Yi Chiang , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Tzung-Bi Shih , Gwendal Grignou , Lee Jones , Yicheng Li , ALSA development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Guenter Roeck =E6=96=BC 2020=E5=B9=B47=E6=9C=889=E6=97= =A5 =E9=80=B1=E5=9B=9B =E4=B8=8A=E5=8D=881:26=E5=AF=AB=E9=81=93=EF=BC=9A > > On Wed, Jul 8, 2020 at 9:17 AM Yu-Hsuan Hsu wrote: > > > > Guenter Roeck =E6=96=BC 2020=E5=B9=B47=E6=9C=888=E6= =97=A5 =E9=80=B1=E4=B8=89 =E4=B8=8B=E5=8D=889:28=E5=AF=AB=E9=81=93=EF=BC=9A > > > > > > On Wed, Jul 8, 2020 at 3:16 AM Enric Balletbo i Serra > > > wrote: > > > > > > > > Hi Yu-Hsuan, > > > > > > > > Thank you for your patch. > > > > > > > > On 8/7/20 9:11, Yu-Hsuan Hsu wrote: > > > > > It is not guaranteed that I2S RX is disabled when the kernel boot= ing. > > > > > For example, if the kernel crashes while it is enabled, it will k= eep > > > > > enabled until the next time EC reboots. Reset I2S RX when probing= to > > > > > fix this issue. > > > > > > > > > > Signed-off-by: Yu-Hsuan Hsu > > > > > --- > > > > > include/linux/platform_data/cros_ec_commands.h | 1 + > > > > > sound/soc/codecs/cros_ec_codec.c | 7 +++++++ > > > > > 2 files changed, 8 insertions(+) > > > > > > > > > > diff --git a/include/linux/platform_data/cros_ec_commands.h b/inc= lude/linux/platform_data/cros_ec_commands.h > > > > > index 69210881ebac8..11ce917ca924c 100644 > > > > > --- a/include/linux/platform_data/cros_ec_commands.h > > > > > +++ b/include/linux/platform_data/cros_ec_commands.h > > > > > @@ -4598,6 +4598,7 @@ enum ec_codec_i2s_rx_subcmd { > > > > > EC_CODEC_I2S_RX_SET_SAMPLE_DEPTH =3D 0x2, > > > > > EC_CODEC_I2S_RX_SET_DAIFMT =3D 0x3, > > > > > EC_CODEC_I2S_RX_SET_BCLK =3D 0x4, > > > > > + EC_CODEC_I2S_RX_RESET =3D 0x5, > > > > > > > > Is this a new command not available in the firmware that is already= in the field? > > > > > > > > > > > > > EC_CODEC_I2S_RX_SUBCMD_COUNT, > > > > > }; > > > > > > > > > > diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/= cros_ec_codec.c > > > > > index 8d45c628e988e..5495214e73e68 100644 > > > > > --- a/sound/soc/codecs/cros_ec_codec.c > > > > > +++ b/sound/soc/codecs/cros_ec_codec.c > > > > > @@ -1034,6 +1034,13 @@ static int cros_ec_codec_platform_probe(st= ruct platform_device *pdev) > > > > > } > > > > > priv->ec_capabilities =3D r.capabilities; > > > > > > > > > > + /* Reset EC codec I2S RX. */ > > > > > + p.cmd =3D EC_CODEC_I2S_RX_RESET; > > > > > + ret =3D send_ec_host_command(priv->ec_device, EC_CMD_EC_COD= EC_I2S_RX, > > > > > + (uint8_t *)&p, sizeof(p), NULL, = 0); > > > > > + if (ret) > > > > > + dev_err(dev, "failed to EC_CODEC_I2S_RESET: %d\n", = ret); > > > > > + > > > > > > > > With an old firmware I suspect this message will appear on every bo= ot, right? > > > > So, to solve the issue and get rid of this error you're forced to u= pgrade the > > > > firmware. Is that true? > > > > > > > > > > It might possibly make more sense to fail this silently and to send > > > EC_CODEC_I2S_RX_DISABLE as backup if it is not supported (-ENOTSUPP > > > can possibly be used as trigger if the call returns it). > > > > > > Also, I don't accept dev_err() if the error is ignored for patches in > > > my scope of responsibility. > > > > > > Guenter > > Thanks for the suggestion. Our plan is to upstream this patch first. > > And then we will merge it into the kernel after the firmware is > > updated. Is it feasible? (I'm not sure whether there is the better way > > if I want to update EC and the kernel at the same time.) > > > > I think calling EC_CODEC_I2S_RX_DISABLE does not make sense because it > > checks the value of i2s_rx_enabled first. If i2s_rx_enabled is false, > > it will skip the function. However, we don't need to reset while the > > i2s_rx_enabled is already false. > > > Exactly my point. If i2s_rx_enabled is false, nothing needs to be > done, and it doesn't hurt if the EC does nothing. If i2s_rx_enabled is > true, it needs to be set to false, which is accomplished by sending > EC_CODEC_I2S_RX_DISABLE. Sorry my bad. If i2s_rx_enabled is false, it will skip and return EC_RES_BUSY. And then we may need to handle one more error. I think it may become too complicated to handle those errors. Could we just merge this change after the firmware updates? So that we don't need to worry about the unsupported command. > > > In addition, since it is a sub-command, it will return > > EC_RES_INVALID_PARAM but not ENOTSUPP if the command is not supported. > > And then EC_RES_INVALID_PARAM will turn into -EPROTO finally so it's > > difficult to do other operators basing on the return value. > > > > You might have to convince Enric to permit another error code to > translate EC_RES_INVALID_PARAM. After all, that would meet his > requirement that the error code must be used in the kernel to accept a > translation. > > Guenter > > > Thanks, > > Yu-Hsuan > > > > > > > > > > platform_set_drvdata(pdev, priv); > > > > > > > > > > ret =3D devm_snd_soc_register_component(dev, &i2s_rx_compon= ent_driver, > > > > >