devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aapo Vienamo <avienamo@nvidia.com>
To: Stefan Agner <stefan@agner.ch>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Mikko Perttunen <mperttunen@nvidia.com>,
	linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-tegra-owner@vger.kernel.org
Subject: Re: [PATCH v2 02/10] dt-bindings: mmc: tegra: Add nvidia,only-1-8-v property
Date: Fri, 27 Jul 2018 11:05:55 +0300	[thread overview]
Message-ID: <20180727110555.1b7ad97d@dhcp-10-21-25-168> (raw)
In-Reply-To: <484a31bdaad6d76b4fbb7d6fa80cbb8d@agner.ch>

On Thu, 26 Jul 2018 15:05:55 +0200
Stefan Agner <stefan@agner.ch> wrote:

> On 26.07.2018 14:19, Aapo Vienamo wrote:
> > Add a property to mark controllers which operate at a 1.8 V fixed I/O
> > voltage.
> > 
> > This feature of the hardware needs to be signaled this way because it
> > cannot be probed at runtime or reliably derived from other properties.  
> 
> Is this really needed? Can we not use vqmmc to determine which voltage
> the controller runs on?
> 
> There is already some precedence in the SDHCI core to determine which
> voltage levels are supported:
> https://lkml.org/lkml/2018/7/5/342

This property is introduced to solve a slightly different issue. The
thing is that supplying a fixed voltage SDHCI controller from a variable
regulator is still a valid configuration. Which means that testing the
capabilities of the regulator doesn't actually describe the SDHCI
controller itself.

In practice this property is used to communicate whether pad
reconfiguration and voltage switching needs to be performed or not. This
cannot be determined from the absence or presence of the pinctrl
properties either because they naturally won't be there on older dtbs.

The logic behind this goes like this: if this property is present,
there's no need to perform pad or regulator reconfiguration and UHS
modes can be enabled. If this property is missing then valid pinctrl and
regulator properties are required to enable UHS signaling. This is
implemented in tegra_sdhci_is_uhs_valid() in "[PATCH v2 03/10] mmc:
tegra: Reconfigure pad voltages during voltage switching"

 -Aapo

  reply	other threads:[~2018-07-27  8:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26 12:19 [PATCH v2 00/10] Tegra SDHCI enable 1.8 V signaling on Tegar210 and Tegra186 Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 01/10] dt-bindings: mmc: tegra: Add pad voltage control properties Aapo Vienamo
2018-07-30 23:22   ` Rob Herring
2018-07-26 12:19 ` [PATCH v2 02/10] dt-bindings: mmc: tegra: Add nvidia,only-1-8-v property Aapo Vienamo
2018-07-26 13:05   ` Stefan Agner
2018-07-27  8:05     ` Aapo Vienamo [this message]
2018-07-30 23:24       ` Rob Herring
2018-07-26 12:19 ` [PATCH v2 03/10] mmc: tegra: Reconfigure pad voltages during voltage switching Aapo Vienamo
2018-07-26 13:33   ` Stefan Agner
2018-07-27  8:44     ` Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 04/10] arm64: dts: Add Tegra210 sdmmc pinctrl voltage states Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 05/10] arm64: dts: Add Tegra186 " Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 06/10] arm64: dts: tegra210-p2180: Allow ldo2 to go down to 1.8 V Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 07/10] arm64: dts: tegra210-p2180: Correct sdmmc4 vqmmc-supply Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 08/10] arm64: dts: tegra210-p2597: Remove no-1-8-v from sdmmc1 Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 09/10] arm64: dts: tegra210: Add nvidia,only-1-8-v to sdmmc4 Aapo Vienamo
2018-07-26 12:19 ` [PATCH v2 10/10] arm64: dts: tegra186: " Aapo Vienamo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180727110555.1b7ad97d@dhcp-10-21-25-168 \
    --to=avienamo@nvidia.com \
    --cc=adrian.hunter@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-tegra-owner@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mperttunen@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=stefan@agner.ch \
    --cc=thierry.reding@gmail.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).