Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp624846ybh; Wed, 15 Jul 2020 10:47:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmr7MIPi74jdpwz7XixNWsdCawNZC7GjMHOgYOwD7MefsIGKMDr1zr/WM7HE3ybk9IxmUS X-Received: by 2002:a17:906:430b:: with SMTP id j11mr124726ejm.270.1594835267318; Wed, 15 Jul 2020 10:47:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594835267; cv=none; d=google.com; s=arc-20160816; b=UoGUpXl2YncYlWcnZ9mdVPhnQsEJtsfrHnl9kDv5NwP00EzIVRvXPzT5Pfx6Ess5/h 5OQZ7hZA0Zq6SUMJ/IsmH0GUXBv60Bcy6wBoz772bfCeg5jXdhHm2y4xwfSRVthLPlgW rWU7Ww+urepFaLfD9ZrNSnGaneC571ngcYsXgOJaYL/gZS6P5lcPwT4bTUiKzaoCnSQu MSpulNt56eio2ykSuBqAN86IfzcJxgU5cHp8bxvWo80UgEXL3SqiCYlrnXr4HSj2WnU+ T5frPgaurkKBr83yOvRsDASlOMEHlm1KexhOPClM6B2/FppjYentA+KsDKshSDqw6MIa bZJg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=jOruZ2QIyryjoGHS/Fnjx0mKHUQjJJIgW81G9TLIhXM=; b=W25SiSu8OBOs2JybRzssFDo5mpThGml1HAXDQSpr11yOvYmhuQY6WtfPqnK9TWybO4 6Hy8cGCPHkHaylJlz8f/1LZ5xi95eKm7673J4h9cmtINxEPH4pnAF6zyOmdeoUDwI3ed UH98I3L2sRqS3oj4Aq/GVqEnelPXOcm+v+DJ4zsOmlAXu4+rhnqZm9pIKzVwaAkdE+rL 3hVucbPYyV1D7/yRzfsO74wLCioXeHanYZ/Y3K4vxM3uHVYa1rP9kzOfwhuNRXOHBVv2 sfvLGe5yQUqZntGjyuTusnvsbn78tx7xsCM8tBNykXhAan0B3KqnUYkFgmHhl66BbPjp 2khQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h28si1938341edj.267.2020.07.15.10.47.24; Wed, 15 Jul 2020 10:47:47 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726812AbgGORoq (ORCPT + 99 others); Wed, 15 Jul 2020 13:44:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725900AbgGORop (ORCPT ); Wed, 15 Jul 2020 13:44:45 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52FBFC061755 for ; Wed, 15 Jul 2020 10:44:45 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: eballetbo) with ESMTPSA id 0794B2A18A0 Subject: Re: [PATCH] ASoC: cros_ec_codec: Reset I2S RX when probing To: Yu-Hsuan Hsu , Guenter Roeck Cc: 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 References: <20200708071117.3070707-1-yuhsuan@chromium.org> From: Enric Balletbo i Serra Message-ID: Date: Wed, 15 Jul 2020 19:44:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yu-Hsuan, On 8/7/20 19:51, Yu-Hsuan Hsu wrote: > Guenter Roeck 於 2020年7月9日 週四 上午1:26寫道: >> >> On Wed, Jul 8, 2020 at 9:17 AM Yu-Hsuan Hsu wrote: >>> >>> Guenter Roeck 於 2020年7月8日 週三 下午9:28寫道: >>>> >>>> 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 booting. >>>>>> For example, if the kernel crashes while it is enabled, it will keep >>>>>> 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/include/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 = 0x2, >>>>>> EC_CODEC_I2S_RX_SET_DAIFMT = 0x3, >>>>>> EC_CODEC_I2S_RX_SET_BCLK = 0x4, >>>>>> + EC_CODEC_I2S_RX_RESET = 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(struct platform_device *pdev) >>>>>> } >>>>>> priv->ec_capabilities = r.capabilities; >>>>>> >>>>>> + /* Reset EC codec I2S RX. */ >>>>>> + p.cmd = EC_CODEC_I2S_RX_RESET; >>>>>> + ret = send_ec_host_command(priv->ec_device, EC_CMD_EC_CODEC_I2S_RX, >>>>>> + (uint8_t *)&p, sizeof(p), NULL, 0); >>>>>> + if (ret) >>>>>> + dev_err(dev, "failed to EC_CODEC_I2S_RESET: %d\n", ret); >>>>>> + What about notify the user that he *must* update their firmware? dev_info(dev, "Missing reset command. Please update your EC firmware.\n") >>>>> >>>>> With an old firmware I suspect this message will appear on every boot, right? >>>>> So, to solve the issue and get rid of this error you're forced to upgrade 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. > How can you ensure that assuming there is already devices in the field? The patch should work for both cases, on devices that has the old firmware and on devices that have the new firmware. You can't guarantee that all the devices will update their firmware. I'd suggest notify the user that should update the EC firmware and fallback/continue when the EC_CODEC_I2S_RX_RESET is not implemented. >> >>> 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 = devm_snd_soc_register_component(dev, &i2s_rx_component_driver, >>>>>>