Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp633499pxb; Tue, 14 Sep 2021 05:35:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxlLC4zwvw0ncr/P51hzc8Ezn/QI8EKIqyhH9smRrhTB6y8TLVNlfyVdGU9jbK7iTQLR/nc X-Received: by 2002:a6b:f214:: with SMTP id q20mr13441140ioh.84.1631622942448; Tue, 14 Sep 2021 05:35:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631622942; cv=none; d=google.com; s=arc-20160816; b=a+U+KcdSkK4NWjR46YKqZWZ5ZqJ7ptT30CUFOvORxIMKQlEVrYDjnn0ZM5tLTeJqmX iG9v7dDunq1Y4bxeuLEoVoI5JhY2nI9qddtC5PUnWjqVbPPckTL/1EIX9410gMhbRhF3 MhY66SyJumR1P0h3bouhSSOnW2bBswXkArDeF80reijjMm/Dp3PwsTStNM3yibyCBiFX S5/eRmzv2gMxPpWAs6q1NbbbLlp+mEh4QMRAN4m/6bdDgB0Nu2qWLe3YyEDlLyO0BLsf Z4vEG65ukdiCEC+jIUNGGNw+6VCBs1j4FrRXWD/PoJ9yOXbfj2Hui66Ln3ZvZNbgQmCG 9kiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=b71EBPDUYYvFgtbJWGxuara2gwoxjFUBAuPR5zJS/So=; b=fqYcEQu+NbnSNnMM8hQ2KHxbbQroFSRzqZzTZOszQMUqq2U+maNtj074AzIQ6np65M gjEvT7KKJC7VjZeNdb0cr+rPoEiwvi2wq38KTYKcKcOlTJAVE9qQJQYrsL1Jb4uljytr +B4YZBgmAMgWxNQGfF3VD00iJUsXeoYb6ZsKW1+775XG0vjqSavobMDo5sZeK8oR6UO+ oILZAO1KI5bOI0wrkkbiYdeM7wSew/ah2UHxXHmI/QGjq0wjWnA3cP8zmD/8gUM0XEz/ KVuR0MGkG3dupQhESfWmm8Z+pqimgK3BjlJJjUfDInF+hkCTauvSaEwwYryoAjWdwpjK SXAQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m1si10903345ilu.13.2021.09.14.05.35.30; Tue, 14 Sep 2021 05:35:42 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232571AbhINMfx (ORCPT + 99 others); Tue, 14 Sep 2021 08:35:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232495AbhINMfw (ORCPT ); Tue, 14 Sep 2021 08:35:52 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6013EC061574 for ; Tue, 14 Sep 2021 05:34:35 -0700 (PDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQ7du-0001I5-RW; Tue, 14 Sep 2021 14:34:30 +0200 Message-ID: <8f5a00dc2b6e3f23e669a8073daa8ddcd5fb1e01.camel@pengutronix.de> Subject: Re: [PATCH v2] arm64: dts: imx8mq-kontron-pitx-imx8m: remove vqmmc-supply node From: Lucas Stach To: Michael Walle Cc: Heiko Thiery , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Fabio Estevam , Shengjiu Wang , Joakim Zhang , Krzysztof Kozlowski , Rob Herring , NXP Linux Team , Pengutronix Kernel Team , Shawn Guo , Sascha Hauer Date: Tue, 14 Sep 2021 14:34:29 +0200 In-Reply-To: <9c4ada4b9ca1e806ea1916f195598b40@walle.cc> References: <20210914072627.24173-1-heiko.thiery@gmail.com> <449f718706fd5af03190bdda986de37aa8fa14e3.camel@pengutronix.de> <79fb60ea9a002ea553a92ea08b28b866@walle.cc> <2dc72116ec935a5a5d7a1a176868b7af7ff3227c.camel@pengutronix.de> <9c4ada4b9ca1e806ea1916f195598b40@walle.cc> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Dienstag, dem 14.09.2021 um 11:39 +0200 schrieb Michael Walle: > Am 2021-09-14 10:52, schrieb Lucas Stach: > > Am Dienstag, dem 14.09.2021 um 10:32 +0200 schrieb Michael Walle: > > > Hi Lucas, > > > > > > Am 2021-09-14 10:20, schrieb Lucas Stach: > > > > Am Dienstag, dem 14.09.2021 um 09:26 +0200 schrieb Heiko Thiery: > > > > > The sw4 output (V_1V8_S0 voltage) from the PMIC is the main supply for > > > > > the 1V8 power domain. It is not only used as supply for the eMMC. > > > > > So this voltage can not be changed and is not allowed to switched off. > > > > > Therefore we do not want to provide this regulator to the SDHC driver > > > > > to > > > > > control this voltage. > > > > > > > > > This specific requirement should not be solved by removing the > > > > regulator connection from the SDHCI node, but instead by constraining > > > > the regulator voltage range to a fixed 3.3V and marking the regulator > > > > as always-on to reflect the hardware requirements in the DT. > > > > > > > > Also if your eMMC vqmmc is a fixed 3.3V, I don't think you need the > > > > faster pinctrl states, as you can't use the faster pin states anyways, > > > > as they require a 1.8V signaling voltage. > > > > > > Are you speaking of the 1.8V signalling modes? As far as I know the > > > IMX SDHC controller will switch the voltage by its own function pin. > > > That is, its not a GPIO. > > > > Ah, I mixed things up here. This is a fixed 1.8V supply, which is valid > > for eMMC, so the high-speed modes are available. My comment still > > applies that this should be fixed by constraining the regulator, not by > > removing the DT connection. > > > > vqmmc is the MMC IO voltage, which can be switched either by the > > function pin, which gets toggled automatically when software does the > > voltage switch, or by explicitly switching the regulator voltage. eMMCs > > are a bit special as they can work with a fixed 1.8V IO supply and > > don't need to start with 3.3V. > > Mh, I have some kind of general question though. > > Lets take the SDHC controller for the SD card, which needs to change > the voltage if you want to use the high speed mode of the cards. Ie. > from 3.3V to 1.8V. The controller does this autonomously with the help > of a pin which is controlled by the controller itself. Will it have a > vqmmc-supply property? And if so what whould the supply be? > If the IO voltage regulator is controlled via the fixed function pin you would not add the vqmmc-supply to the DT, as the regulator isn't known to Linux in that case. The vqmmc-supply should be used when you have a regulator which is controlled via some other path than the fixed function pin, or if the regulator is fixed. By having the connection to the fixed regulator, the MMC core is able to see that certain modes of operation are not available. Regards, Lucas