Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6761681imu; Wed, 14 Nov 2018 06:37:07 -0800 (PST) X-Google-Smtp-Source: AJdET5faerhd3gOCrH3pMXjeoQ2D8OW8RnWgeF90uKvGLw8dsMF8LLYRFnsehUxDuUBouD+rTj0T X-Received: by 2002:a17:902:6848:: with SMTP id f8mr2128625pln.300.1542206227156; Wed, 14 Nov 2018 06:37:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542206227; cv=none; d=google.com; s=arc-20160816; b=0Bw6GZjtC9nlsfv+MFrQU0Z9FaiQbNbw8H8SFgFx5h+e1AK0xOtWX3vb6/22vRgHj2 AhF4XJQDlB53hepCSBWyI/87IQJhFAYYR0eh7Ir1/AGkiDZsbke9FaEe1bpCCTlcHCiG Bmyglho1tfpQAQmBndnKXNFmpXmuBwFJtUjorgsGd9wxa2bb4MzUuRMnGDDS9d5/MEcz P05uVXkHtrDq1iKPiucc5Tlu1fZijmK7xA8/n86jFjUmYOnyNUPB6ZO8zfx4voxMpQ1s Tb8aRNoyCi81RS4bWW83Gbe08uWgGTedaSXDbn4hudqfS+XL6ufLEaGA9IYcewv6d8Xm t7gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:dmarc-filter :dkim-signature:dkim-signature; bh=baJeU9R+v5Jc+2Sl0sOJfQlJgTMCXy6/eC/TaR3NA1U=; b=wndKFvudD8A9EuwM73lseQIha2+v6HFUynaDhqX098GGQl37kKCrs2DV/H8yGz4ma7 AR1KLbeW3EQwlOhsYqtLHrEd7wf2fx3N9B9dlV9komb9/KB+ASc/KaQ9biG/13++630S 4gAoJEUArtO/QgVj5xgX3wDi+qtvv/Bx1dFqzk1c522DQDBdx2q1iYuDj9n8WJ1fexnj 0GoyIomFgBW5j3On2I8TCU0YLFXURZwWzUy7hfWHJ4nIsWos8Z+Lt5ANYuKsTsXGQ4hE FlO8KnJWoUYC9nn0fspReMyi95hin54Mvk/2V5IvOnDIuT3HEafNyGBsO9gNHg2TvTC0 NmNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=ffUZ1F5u; dkim=pass header.i=@codeaurora.org header.s=default header.b=HXWgdq53; 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 w22-v6si23871606plp.110.2018.11.14.06.36.51; Wed, 14 Nov 2018 06:37:07 -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=pass header.i=@codeaurora.org header.s=default header.b=ffUZ1F5u; dkim=pass header.i=@codeaurora.org header.s=default header.b=HXWgdq53; 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 S1732825AbeKOAju (ORCPT + 99 others); Wed, 14 Nov 2018 19:39:50 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:40042 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727357AbeKOAju (ORCPT ); Wed, 14 Nov 2018 19:39:50 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id CA9EA6044B; Wed, 14 Nov 2018 14:36:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1542206180; bh=VlEiyXe+KzKKz+Js0d8x3vINvYdHPJs429FntIfkbOQ=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=ffUZ1F5uEC7MbpE68L21embclgSRHKHq2K+96SphoyTvaTaTiLKoOrL+ZZD5Idfot o/PKbEwaD1czgvhIHimOh59JO9FZPabfXkdp+Z6HowVRN+hS9KP674Vk+l60fq9+fA OlfiMPIULMmwi8AbQrB8hUlRYfUV6u4TEbvkqmSE= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from [192.168.0.104] (unknown [183.83.73.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vbadigan@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5F00D6044B; Wed, 14 Nov 2018 14:36:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1542206179; bh=VlEiyXe+KzKKz+Js0d8x3vINvYdHPJs429FntIfkbOQ=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=HXWgdq53yema/ppJvyUYpR5xMo3wndyTnrn2u3ZkWPBcnxUcBs3JU3gZ4HxGuyxXr foL2RH5kWJjgIH+85RaD0MsLw1tShbyWfUyIlqMXHGBvjDaAsxxpwjO6vPmbP4SVcC OkV//Z4SecOr1F78nM24+mW3i7oaZaDo3aQODypQ= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5F00D6044B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=vbadigan@codeaurora.org Subject: Re: [PATCH V3 1/3] mmc: sdhci: Allow platform controlled voltage switching From: Veerabhadrarao Badiganti To: Evan Green Cc: adrian.hunter@intel.com, Ulf Hansson , robh+dt@kernel.org, Doug Anderson , asutoshd@codeaurora.org, riteshh@codeaurora.org, stummala@codeaurora.org, sayali , linux-mmc@vger.kernel.org, linux-arm-msm@vger.kernel.org, vviswana@codeaurora.org, linux-kernel@vger.kernel.org References: <1539004739-32060-1-git-send-email-vbadigan@codeaurora.org> <1539004739-32060-2-git-send-email-vbadigan@codeaurora.org> Message-ID: <9a4708c8-cc43-a690-7ef7-da351eb1f967@codeaurora.org> Date: Wed, 14 Nov 2018 20:06:04 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/12/2018 10:49 PM, Veerabhadrarao Badiganti wrote: > > On 10/17/2018 3:39 AM, Evan Green wrote: >> On Mon, Oct 8, 2018 at 6:22 AM Veerabhadrarao Badiganti >> wrote: >>> From: Vijay Viswanath >>> >>> Some controllers can have internal mechanism to inform the SW that it >>> is ready for voltage switching. For such controllers, changing voltage >>> before the HW is ready can result in various issues. >>> >>> During setup/cleanup of host, check whether regulator enable/disable >>> was already done by platform driver. >>> >>> Signed-off-by: Vijay Viswanath >>> Signed-off-by: Veerabhadrarao Badiganti >>> --- >>>   drivers/mmc/host/sdhci.c | 32 +++++++++++++++++++------------- >>>   drivers/mmc/host/sdhci.h |  1 + >>>   2 files changed, 20 insertions(+), 13 deletions(-) >>> >>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c >>> index 99bdae5..ea7ce1d 100644 >>> --- a/drivers/mmc/host/sdhci.c >>> +++ b/drivers/mmc/host/sdhci.c >>> @@ -3616,6 +3616,7 @@ int sdhci_setup_host(struct sdhci_host *host) >>>          unsigned int override_timeout_clk; >>>          u32 max_clk; >>>          int ret; >>> +       bool enable_vqmmc = false; >>> >>>          WARN_ON(host == NULL); >>>          if (host == NULL) >>> @@ -3629,9 +3630,12 @@ int sdhci_setup_host(struct sdhci_host *host) >>>           * the host can take the appropriate action if regulators >>> are not >>>           * available. >>>           */ >>> -       ret = mmc_regulator_get_supply(mmc); >>> -       if (ret) >>> -               return ret; >>> +       if (!mmc->supply.vqmmc) { >>> +               ret = mmc_regulator_get_supply(mmc); >>> +               if (ret) >>> +                       return ret; >>> +               enable_vqmmc  = true; >>> +       } >> Did you not like my suggestion in the previous patch of changing >> mmc_regulator_get_supply to only get supplies that were not set >> previously? What you have here is almost the same, except you've got >> this weird coupling where if vqmmc is already present, you implicitly >> skip looking at vmmc entirely (since mmc_regulator_get_supply does >> more than just get vqmmc). > > sure. Will update mmc_regulator_get_supply() as you suggested. > >>>          DBG("Version:   0x%08x | Present:  0x%08x\n", >>>              sdhci_readw(host, SDHCI_HOST_VERSION), >>> @@ -3880,7 +3884,15 @@ int sdhci_setup_host(struct sdhci_host *host) >>>                  mmc->caps |= MMC_CAP_NEEDS_POLL; >>> >>>          if (!IS_ERR(mmc->supply.vqmmc)) { >>> -               ret = regulator_enable(mmc->supply.vqmmc); >>> +               if (enable_vqmmc) { >>> +                       ret = regulator_enable(mmc->supply.vqmmc); >>> +                       if (ret) { >>> +                               pr_warn("%s: Failed to enable vqmmc >>> regulator: %d\n", >>> +                                       mmc_hostname(mmc), ret); >>> +                               mmc->supply.vqmmc = ERR_PTR(-EINVAL); >>> +                       } >>> +                       host->vqmmc_enabled = !ret; >>> +               } >>> >>>                  /* If vqmmc provides no 1.8V signalling, then >>> there's no UHS */ >>>                  if >>> (!regulator_is_supported_voltage(mmc->supply.vqmmc, 1700000, >>> @@ -3893,12 +3905,6 @@ int sdhci_setup_host(struct sdhci_host *host) >>>                  if >>> (!regulator_is_supported_voltage(mmc->supply.vqmmc, 2700000, >>>                                                      3600000)) >>>                          host->flags &= ~SDHCI_SIGNALING_330; >>> - >>> -               if (ret) { >>> -                       pr_warn("%s: Failed to enable vqmmc >>> regulator: %d\n", >>> -                               mmc_hostname(mmc), ret); >>> -                       mmc->supply.vqmmc = ERR_PTR(-EINVAL); >>> -               } >>>          } >>> >>>          if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V) { >>> @@ -4136,7 +4142,7 @@ int sdhci_setup_host(struct sdhci_host *host) >>>          return 0; >>> >>>   unreg: >>> -       if (!IS_ERR(mmc->supply.vqmmc)) >>> +       if (host->vqmmc_enabled) >>>                  regulator_disable(mmc->supply.vqmmc); >>>   undma: >>>          if (host->align_buffer) >>> @@ -4154,7 +4160,7 @@ void sdhci_cleanup_host(struct sdhci_host *host) >>>   { >>>          struct mmc_host *mmc = host->mmc; >>> >>> -       if (!IS_ERR(mmc->supply.vqmmc)) >>> +       if (host->vqmmc_enabled) >>>                  regulator_disable(mmc->supply.vqmmc); >>> >>>          if (host->align_buffer) >>> @@ -4287,7 +4293,7 @@ void sdhci_remove_host(struct sdhci_host >>> *host, int dead) >>> >>>          tasklet_kill(&host->finish_tasklet); >>> >>> -       if (!IS_ERR(mmc->supply.vqmmc)) >>> +       if (host->vqmmc_enabled) >>>                  regulator_disable(mmc->supply.vqmmc); >>> >>>          if (host->align_buffer) >>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h >>> index b001cf4..3c28152 100644 >>> --- a/drivers/mmc/host/sdhci.h >>> +++ b/drivers/mmc/host/sdhci.h >>> @@ -524,6 +524,7 @@ struct sdhci_host { >>>          bool pending_reset;     /* Cmd/data reset is pending */ >>>          bool irq_wake_enabled;  /* IRQ wakeup is enabled */ >>>          bool v4_mode;           /* Host Version 4 Enable */ >>> +       bool vqmmc_enabled;     /* Vqmmc is enabled */ >> I still don't love this, since it doesn't mean what it says. Everyone >> else that has a vqmmc_enabled member uses it to actually mean "vqmmc >> is enabled", but this doesn't mean that. For example, you don't clear >> this when you disable the regulator in patch 3, so this would be set >> even if the regulator is disabled, and you don't set it when sdhci >> enables the regulator, so the regulator is on when this flag is not >> set. >> Hi Evan This flag is meant to say "disable vqmmc *only* if it is enabled by host driver (sdhci_host)". If host driver doesn't enable vqmmc (enabled by platfrm driver) or if it fails to enable it, then don't call disable vqmmc. Agree with you, the present name is not conveying its purpose. It must be something like "vqmmc_enabled_by_host". Please let me know if you have any suggestions on this name. >> At the very least, I think a rename is in order. I'm struggling with >> the rename, since >> "vqmmc_pltfrm_enable_but_feel_free_to_call_set_voltage_anywhere" is >> too long. I guess vqmmc_pltfrm_enabled is the best I've got for now. > > Sure. Will rename it. > >>>          struct mmc_request *mrqs_done[SDHCI_MAX_MRQS];  /* Requests >>> done */ >>>          struct mmc_command *cmd;        /* Current command */ >>> -- >>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation >>> Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >>> Linux Foundation Collaborative Project. >>> >