Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp524592imm;
        Fri, 27 Jul 2018 01:07:49 -0700 (PDT)
X-Google-Smtp-Source: AAOMgpdPlQFgVdGfscrUPT7D+oYq+j9oz35gHxrSvvrzIKaOp2DdyViPHTwDk2P34JGDFWa/FrtY
X-Received: by 2002:a65:5cc5:: with SMTP id b5-v6mr5031783pgt.425.1532678869716;
        Fri, 27 Jul 2018 01:07:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1532678869; cv=none;
        d=google.com; s=arc-20160816;
        b=EUgUnqz1nTHRHYSAXkBm/m0vdHaNyd/CqigVgjfqBJh7er538LBfK92Lnas8dPF2w8
         Z0VWuS71K7syIGf4OoTv1V9aGoRo7+KIHDNZr9NPhySodZv2xB2gXZvAVkJGTlFTEG5h
         WBJbtHS2E47oO46W7AJiTL7bVtbGeixvbHKx8CWMEdjTJm6eEDhOlGSfbUOFAgC/9IjL
         b9O1QMsRy6rJVjJOb6yqDDU0KyWQ6Z1DhGCGmVC4/5C/X5eCAtYEyYlo2IpD1TF1CbvJ
         wkRILzMfuT+aPTHnoiQifAyXen1lGEIVqHUdOugyComwBgFOZvAjGPFhI1iTdzNAcq1X
         VH1A==
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:mime-version
         :references:in-reply-to:message-id:subject:cc:to:from:date
         :arc-authentication-results;
        bh=bHHTT+LN2j4mJOePviq8rQ09E6hQH6C+1ZPjKRtN1dk=;
        b=uUp208XBfcew/z5GNHk/sDz+5kQGDzSbizWyHkaNrPhJsW4ChIRaLnv4dh68tUptyB
         WdJRTdCv07eFF3+1iGb/PNRI5c8CVys2vI97be992D/oajm+v0XJC764jVjp++xum52I
         DG0i2IpX8aBTsDVLyTRpampBa4S4I+uVROrMAluJtlHA3S8ja6mmpLPXH55bGTfTpFMK
         umI5hcgBBdNGfiwKj5X7YUopNCzeHQ65NE8Yv3A08450FFoYx1OcHTujrAIkvpWK5Ji3
         jUWGg7R6RyLKOUqCUDfIef6FQLQDfcGst5bjZ8SO3DCHetWxTNaifJX2NdXqjRI6q8i6
         cUSg==
ARC-Authentication-Results: i=1; mx.google.com;
       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;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
        by mx.google.com with ESMTP id c18-v6si3374067pgh.530.2018.07.27.01.07.35;
        Fri, 27 Jul 2018 01:07:49 -0700 (PDT)
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;
       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;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1730205AbeG0J0s (ORCPT <rfc822;kernelgary@gmail.com>
        + 99 others); Fri, 27 Jul 2018 05:26:48 -0400
Received: from hqemgate16.nvidia.com ([216.228.121.65]:16333 "EHLO
        hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1729445AbeG0J0s (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 27 Jul 2018 05:26:48 -0400
Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com (using TLS: TLSv1, AES128-SHA)
        id <B5b5ad2620002>; Fri, 27 Jul 2018 01:05:54 -0700
Received: from HQMAIL101.nvidia.com ([172.20.161.6])
  by hqpgpgate101.nvidia.com (PGP Universal service);
  Fri, 27 Jul 2018 01:06:05 -0700
X-PGP-Universal: processed;
        by hqpgpgate101.nvidia.com on Fri, 27 Jul 2018 01:06:05 -0700
Received: from dhcp-10-21-25-168 (10.21.25.201) by HQMAIL101.nvidia.com
 (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Jul
 2018 08:06:01 +0000
Date:   Fri, 27 Jul 2018 11:05:55 +0300
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
Message-ID: <20180727110555.1b7ad97d@dhcp-10-21-25-168>
In-Reply-To: <484a31bdaad6d76b4fbb7d6fa80cbb8d@agner.ch>
References: <1532607560-11253-1-git-send-email-avienamo@nvidia.com>
        <1532607560-11253-3-git-send-email-avienamo@nvidia.com>
        <484a31bdaad6d76b4fbb7d6fa80cbb8d@agner.ch>
X-NVConfidentiality: public
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.21.25.201]
X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To HQMAIL101.nvidia.com
 (172.20.187.10)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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