Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1902311ybh; Fri, 17 Jul 2020 04:30:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyT+GqDXeDYBjvBGcrN1tp5oJik41dK3vKBfuuOIeP7QijheJaZDu6cEeFqfuR5yO9CWsat X-Received: by 2002:a17:906:3c42:: with SMTP id i2mr8705208ejg.14.1594985431786; Fri, 17 Jul 2020 04:30:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594985431; cv=none; d=google.com; s=arc-20160816; b=yi4tA8x5Pi9/FfeGJL6e7VuQmeaBXUp9U1fC28/L31iLwqb1dxotgcEHheo0eI5AgD 2b8NAmGbtBJBqlCaSRws6b5GNpjPuT5Rt2s49GLyg0EDG9V0q3Y+6Aoqclkt0HQBWPyY RYYN8scwp8WDkacK5InZJOwaxlOjtvwHniM7W6mIlrV+42Ub5ycXKI0OMmos87HPXrOm 6/r4LO8p7z8HbqEKpGzPgM4Fo+TMWMo3LcXwWQzCCcFm0Jo5X1qSjD5vSWqhPkqUm8pB ivBW4Vn9qs/CrUGFW3kgpobySxxHasuD+8NkyvUq81YTLPzytuvU1PDMVNiI/Tt57JAa 1SrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5E9FxeV8r0Kl53Po7D0HEeofAYDOqosJLkJd0MD2Tk8=; b=KkNCQU2xJLi8CnStisKD0umWMVNy2VUdOCkueVxYOAflHPCiBKxmALS/KiUrBegKgi MXxWe6RK/miz4BlXLju+1tNCNCtyH7WcbJQy19ws+l83G35H/g5S00tZXs/k+8Ib3LOe dpVvVmLuMBiEW+z5bigzD9fkX4k6dNRrFIayQtRPxx7ze6ZcUoUPql7is/CaUW8manpu 6HDxG1gJyPHmw4G/IUvu4sHWY+HLV7lnSdxgluHOJpKZTztKz/2pLtNW0Is1G8uzQ3uU wvKumiQ6fPFERH9LkOU2dpLNcz2IW+oGLm+nZyNJAYYksDPXN4TdXjMOyEiIY+LupJOc FeMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=nVbzsZEb; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f20si5784903edc.396.2020.07.17.04.30.06; Fri, 17 Jul 2020 04:30:31 -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=@linaro.org header.s=google header.b=nVbzsZEb; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726383AbgGQL0o (ORCPT + 99 others); Fri, 17 Jul 2020 07:26:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726229AbgGQL0n (ORCPT ); Fri, 17 Jul 2020 07:26:43 -0400 Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D5D7C08C5C0 for ; Fri, 17 Jul 2020 04:26:43 -0700 (PDT) Received: by mail-vk1-xa44.google.com with SMTP id s192so2034313vkh.3 for ; Fri, 17 Jul 2020 04:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5E9FxeV8r0Kl53Po7D0HEeofAYDOqosJLkJd0MD2Tk8=; b=nVbzsZEbmCTZXaV8MAK2Ht6VC63/rhQuD/TF1ZrBIFHDIw3D90nYg9iaM4c3FusD8g At6NQM9+nZBOluA4bvaXZufJJcxv7iaCZab5H258ZRcL/IX9Ko1O+B1rGjlHivBQmeTM nutJ2HXsrwg8RL7YCZpmHswJ4ZB/kOm9foPD879qycvpf/VpO/9k61rBIV/6/itIjOwO UdT/3bl7gEb+WEcrBYoRN9QJfcZ189r/yq5i4Tck5xBUTzNN1E3yO+rdjRFoYCt6s42X XlQ8FvTr8SvWcIgKxRmPZDsW6mCPVHWqtK17shVzIqrl4vFaFOkmoknFMT0NR035EaDZ b8tw== 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; bh=5E9FxeV8r0Kl53Po7D0HEeofAYDOqosJLkJd0MD2Tk8=; b=WZ3s9GH/XZupa3BifEjkbzogE1YyDxmFxAvjviaBGhSv9QZkYiBxoTrT/SC198Ffrs g2CWj8FTqwP7mIb3koj/eLZVgXTpauK2BjM6Q7jvi+N7uRXwqxziGQO7dPh9itDa3V5z lPtj3cmSvagnFL7XxeZCanbkasTbcMxhKrh2dmbDjlnZZIXvCpwygsODb9tdZ5X8rZid cTCRTkSQPrT85F0MJYCYB6a/6xMXje0XSsagktjM6Y3BVA7NTQulaog0zfA3s9pcDFc7 CzHO+7oFU2BEkVRA8x+0dTVHcxNekToxEvAMNGXxE5KiLN3QvTYTaZTRYbcIazRQIHh/ aStg== X-Gm-Message-State: AOAM530w9Luqcl+GhX7Oe6gVdPw/SgjefUAypTTQmOmP8rIgEdYRO9M9 B6jOTIK2TBFQJcfqXR1pMpYIDegF/h8zJLUJgHLMQg== X-Received: by 2002:a1f:3f0f:: with SMTP id m15mr6733654vka.53.1594985202239; Fri, 17 Jul 2020 04:26:42 -0700 (PDT) MIME-Version: 1.0 References: <20200710110819.28965-1-benchuanggli@gmail.com> In-Reply-To: <20200710110819.28965-1-benchuanggli@gmail.com> From: Ulf Hansson Date: Fri, 17 Jul 2020 13:26:05 +0200 Message-ID: Subject: Re: [RFC PATCH V3 02/21] mmc: core: UHS-II support, modify power-up sequence To: Ben Chuang Cc: Adrian Hunter , "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , Ben Chuang , Takahiro Akashi , greg.tu@genesyslogic.com.tw Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 10 Jul 2020 at 13:07, Ben Chuang wrote: > > From: AKASHI Takahiro > > According to Fig. 3-35 in "SD Host Controller Simplified Spec. Ver4.20": > - Prepare vdd1, vdd2 and ios.timing for using after/in step (2) > - chip_select is not used in UHS-II, used to return to the legacy flow Thanks for pointing to the spec, but please explain why/what/how for the change - as this helps me to review. I am going to stop commenting on each patch's commit message, beyond this patch - as it seems the same comment applies to more patches. > > Signed-off-by: Ben Chuang > Signed-off-by: AKASHI Takahiro > --- > drivers/mmc/core/core.c | 62 ++++++++++++++++++++++++------------ > drivers/mmc/core/regulator.c | 14 ++++++++ > 2 files changed, 56 insertions(+), 20 deletions(-) > > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c > index 8d2b808e9b58..85c83c82ad0c 100644 > --- a/drivers/mmc/core/core.c > +++ b/drivers/mmc/core/core.c > @@ -1315,33 +1315,51 @@ void mmc_power_up(struct mmc_host *host, u32 ocr) > if (host->ios.power_mode == MMC_POWER_ON) > return; > > - mmc_pwrseq_pre_power_on(host); > + if (host->flags & MMC_UHS2_SUPPORT) { > + /* TODO: handle 'ocr' parameter */ > + host->ios.vdd = fls(host->ocr_avail) - 1; > + host->ios.vdd2 = fls(host->ocr_avail_uhs2) - 1; > + if (mmc_host_is_spi(host)) > + host->ios.chip_select = MMC_CS_HIGH; > + else > + host->ios.chip_select = MMC_CS_DONTCARE; > + host->ios.timing = MMC_TIMING_UHS2; If I understand correctly, the intent is to always try to initialize the UHS-II interface/phy if that is supported. That doesn't seem correct to me. What about if the SD card doesn't support UHS-II, then we should use the legacy SD interface instead right? Or perhaps the MMC_UHS2_SUPPORT bit becomes cleared somewhere in the error path when first trying to initialize an UHS-II card, from subsequent changes? So, assuming that is the intent then, I am still not sure about this approach. What about if we instead always start with legacy SD initialization? When we have read the OCR register, via mmc_send_app_op_cond(), we can check if the card supports UHS-II by looking at the UHS-II Card Status (bit 29). If it turns out that the card supports UHS-II and the host does as well, then we do a mmc_power_off() to completely reset the card/host/phy. Then we can call into a UHS-II specific path, that tries to power on and initialize things according to the UHS-II spec. In this way, we are going to prioritize initialization of legacy SD cards to remain quick, as we won't try to use UHS-II unless the card supports it. Moreover, I get the impression that we can keep the existing code more as is - and instead introduce UHS-II specifics in a separate path. This also also for UHS-II specific optimizations, I think. > + } else { > + mmc_pwrseq_pre_power_on(host); > > - host->ios.vdd = fls(ocr) - 1; > - host->ios.power_mode = MMC_POWER_UP; > - /* Set initial state and call mmc_set_ios */ > - mmc_set_initial_state(host); > + host->ios.vdd = fls(ocr) - 1; > + host->ios.power_mode = MMC_POWER_UP; > + /* Set initial state and call mmc_set_ios */ > + mmc_set_initial_state(host); > > - mmc_set_initial_signal_voltage(host); > + mmc_set_initial_signal_voltage(host); > > - /* > - * This delay should be sufficient to allow the power supply > - * to reach the minimum voltage. > - */ > - mmc_delay(host->ios.power_delay_ms); > - > - mmc_pwrseq_post_power_on(host); > + /* > + * This delay should be sufficient to allow the power supply > + * to reach the minimum voltage. > + */ > + mmc_delay(host->ios.power_delay_ms); > > + mmc_pwrseq_post_power_on(host); > + } > host->ios.clock = host->f_init; > - > host->ios.power_mode = MMC_POWER_ON; > + > mmc_set_ios(host); > > - /* > - * This delay must be at least 74 clock sizes, or 1 ms, or the > - * time required to reach a stable voltage. > - */ > - mmc_delay(host->ios.power_delay_ms); > + if (host->flags & MMC_UHS2_SUPPORT) > + /* > + * This delay should be sufficient to allow the power supply > + * to reach the minimum voltage. > + */ > + /* TODO: avoid an immediate value */ > + mmc_delay(10); > + else > + /* > + * This delay must be at least 74 clock sizes, or 1 ms, or the > + * time required to reach a stable voltage. > + */ > + mmc_delay(host->ios.power_delay_ms); > } > > void mmc_power_off(struct mmc_host *host) > @@ -2307,7 +2325,11 @@ void mmc_start_host(struct mmc_host *host) > > if (!(host->caps2 & MMC_CAP2_NO_PRESCAN_POWERUP)) { > mmc_claim_host(host); > - mmc_power_up(host, host->ocr_avail); > + > + /* Power up here will make UHS2 init ugly. */ > + if (!(host->caps & MMC_CAP_UHS2)) > + mmc_power_up(host, host->ocr_avail); > + According to my suggestions, then this would not be needed. > mmc_release_host(host); > } > > diff --git a/drivers/mmc/core/regulator.c b/drivers/mmc/core/regulator.c > index 96b1d15045d6..05556225d9ac 100644 > --- a/drivers/mmc/core/regulator.c > +++ b/drivers/mmc/core/regulator.c > @@ -247,6 +247,7 @@ int mmc_regulator_get_supply(struct mmc_host *mmc) > > mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc"); > mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc"); > + mmc->supply.vmmc2 = devm_regulator_get_optional(dev, "vmmc2"); Please move the regulator thingy here into a separate patch. Please make sure corresponding header file, adding the vmmc2 to it is part of that change as well. > > if (IS_ERR(mmc->supply.vmmc)) { > if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER) > @@ -266,6 +267,19 @@ int mmc_regulator_get_supply(struct mmc_host *mmc) > dev_dbg(dev, "No vqmmc regulator found\n"); > } > > + if (IS_ERR(mmc->supply.vmmc2)) { > + if (PTR_ERR(mmc->supply.vmmc2) == -EPROBE_DEFER) > + return -EPROBE_DEFER; > + dev_dbg(dev, "No vmmc2 regulator found\n"); > + } else { > + ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc2); > + if (ret > 0) > + mmc->ocr_avail_uhs2 = ret; > + else > + dev_warn(dev, "Failed getting UHS2 OCR mask: %d\n", > + ret); > + } > + > return 0; > } > EXPORT_SYMBOL_GPL(mmc_regulator_get_supply); > -- > 2.27.0 > Kind regards Uffe