| Message ID | 20230213155833.1644366-7-frieder@fris.de |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2425440wrn;
Mon, 13 Feb 2023 08:03:25 -0800 (PST)
X-Google-Smtp-Source:
AK7set+LKY6DV81E5ttZZijdAK9O0X01iobAkCpp7S547QKwsi/9Nu2Ptw0SVT3MeR1x05XstsF+
X-Received: by 2002:a17:90a:194:b0:234:8cd:c0e4 with SMTP id
20-20020a17090a019400b0023408cdc0e4mr2824271pjc.23.1676304205222;
Mon, 13 Feb 2023 08:03:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1676304205; cv=none;
d=google.com; s=arc-20160816;
b=hhXtu5FziX8mPg7PJw5ixOuXZ8c8syd+psg5f8FBFaGN80X8AfQUG+WOarWeD39QBC
l2dqTvXmnP11GtGpA2AzzaDyGkcs4NGDdhK4pfwJVbEWgIh7glCpPbRJ5gPLAalIUapg
uejdq466j7mvY1XZiLri0XjGc7W+j5ledb5R45JAucjTfrO7nJHjtznWRsyI+FOu289I
YqMxCObHyY8mQfxk+7Ch9kgihNKYTc6Nzy2pRcUDPX67pN3dIjSNWEpjknXuKV1+rVsZ
H0a4ehIAAVgmTVzsx4W83lSF/Gw6U/5DOqfI23WBcaBId/9r5zvOORTg641jhAjXW+7K
SyHA==
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
:references:in-reply-to:message-id:date:subject:cc:to:from
:dkim-signature;
bh=64grUIMOl3DlMA5X19kZ/0poE7psMX9YME1d/5PcVes=;
b=qdzF2yekgSdQRBnljVsSqygMLtZztRrYUvtwNZjzt5YeqWZ4+ILSMS9qOkwPc5WeOC
5KQNUaSyx1RigKydVnil+eHPOQYsYWkcN3QvdoAT0rX1vwT8PAW6fBua5GGUTrArui3d
qBksahHiI72pqdegxwlUG8ZvfdHTBT3PrDGS0iMOhCa2CNsT91ORTdGprpBJ+C9ngHx/
hYekuuRZCe386OL8RFxOtCAowSTZZ6j59DCYOIHAu0m6RTaUe3ChBAQsgEMLVYmlyp0w
Rgs6eUTL5QO2qrC7dxIdc4K0KgYT6+V7q+62zaqSASBc32LCb53kgj2wY0yGbUX5A24j
Fv+A==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@fris.de header.s=dkim header.b=L1VOGI7O;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fris.de
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
pg9-20020a17090b1e0900b0023418ec51f8si972936pjb.136.2023.02.13.08.03.12;
Mon, 13 Feb 2023 08:03:25 -0800 (PST)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
dkim=pass header.i=@fris.de header.s=dkim header.b=L1VOGI7O;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fris.de
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S231354AbjBMQBG (ORCPT <rfc822;tebrre53rla2o@gmail.com>
+ 99 others); Mon, 13 Feb 2023 11:01:06 -0500
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50802 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S231324AbjBMQBE (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Mon, 13 Feb 2023 11:01:04 -0500
Received: from mail.fris.de (mail.fris.de [IPv6:2a01:4f8:c2c:390b::1])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADFE6170B;
Mon, 13 Feb 2023 08:00:53 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)
with ESMTPSA id EBEF3BFBAC;
Mon, 13 Feb 2023 17:00:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fris.de; s=dkim;
t=1676304051; h=from:subject:date:message-id:to:cc:mime-version:
content-transfer-encoding:in-reply-to:references;
bh=64grUIMOl3DlMA5X19kZ/0poE7psMX9YME1d/5PcVes=;
b=L1VOGI7OPRvZoeEBiIL1YvtAeloc7cXo3N7YfGaR5Hi1zjjfZ5jesKbiFzSvYqAhnI9AZF
5OSEmWIZIcsKIWFFN1UTBEljQoqM3M9ZjYKXJTZu8ycyPP/T0eusqmZKlgyWhMVdos9mwR
fE20FwWJbTN6Ez+EuVTv2B5PcQuHrgdQVCaWncDr6laHOVhuIT0B/UcFZa2qdvp/KupjFm
Qqcdwu+SFZDcrbZwnyl4oHCjvhMzQ1tm++X+d+hm01mV/d8Qcc0An/a2Ua9m7jkCZDR8W0
mbch8+RupRbo5WEChlWVcAwnBvBRaMVywoVog+751zcBgsztjq5hR2bBeTPk8g==
From: Frieder Schrempf <frieder@fris.de>
To: devicetree@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>
Cc: Marek Vasut <marex@denx.de>,
Frieder Schrempf <frieder.schrempf@kontron.de>,
Fabio Estevam <festevam@gmail.com>,
Heiko Thiery <heiko.thiery@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
NXP Linux Team <linux-imx@nxp.com>,
Oleksij Rempel <linux@rempel-privat.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>
Subject: [PATCH 6/6] arm64: dts: imx8mm-kontron: Add support for reading
SD_VSEL signal
Date: Mon, 13 Feb 2023 16:58:24 +0100
Message-Id: <20230213155833.1644366-7-frieder@fris.de>
In-Reply-To: <20230213155833.1644366-1-frieder@fris.de>
References: <20230213155833.1644366-1-frieder@fris.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Last-TLS-Session-Version: TLSv1.3
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS
autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1757732358098449478?=
X-GMAIL-MSGID: =?utf-8?q?1757732358098449478?=
|
| Series |
Use correct LDO5 control registers for PCA9450
|
|
Commit Message
Frieder Schrempf
Feb. 13, 2023, 3:58 p.m. UTC
From: Frieder Schrempf <frieder.schrempf@kontron.de> This fixes the LDO5 regulator handling of the pca9450 driver by taking the status of the SD_VSEL into account to determine which configuration register is used for the voltage setting. Even without this change there is no functional issue, as the code for switching the voltage in sdhci.c currently switches both, the VSELECT/SD_VSEL signal and the regulator voltage at the same time and doesn't run into an invalid corner case. We should still make sure, that we always use the correct register when controlling the regulator. At least in U-Boot this fixes an actual bug where the wrong IO voltage is used. Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> --- arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 6 +++--- arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 6 +++--- arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 1 + arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi | 1 + 4 files changed, 8 insertions(+), 6 deletions(-)
Comments
On 2/13/23 16:58, Frieder Schrempf wrote: > From: Frieder Schrempf <frieder.schrempf@kontron.de> > > This fixes the LDO5 regulator handling of the pca9450 driver by > taking the status of the SD_VSEL into account to determine which > configuration register is used for the voltage setting. > > Even without this change there is no functional issue, as the code > for switching the voltage in sdhci.c currently switches both, the > VSELECT/SD_VSEL signal and the regulator voltage at the same time > and doesn't run into an invalid corner case. > > We should still make sure, that we always use the correct register > when controlling the regulator. At least in U-Boot this fixes an > actual bug where the wrong IO voltage is used. > > Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> I may have a kind-of obvious request, since we removed those SD_VSEL very recently from other boards, could you just revert all those patches and only fill in the SION bit in V2 on all those boards too ? That way, we fix the LDO5 regulator for everyone who used it before.
On 13.02.23 17:08, Marek Vasut wrote: > On 2/13/23 16:58, Frieder Schrempf wrote: >> From: Frieder Schrempf <frieder.schrempf@kontron.de> >> >> This fixes the LDO5 regulator handling of the pca9450 driver by >> taking the status of the SD_VSEL into account to determine which >> configuration register is used for the voltage setting. >> >> Even without this change there is no functional issue, as the code >> for switching the voltage in sdhci.c currently switches both, the >> VSELECT/SD_VSEL signal and the regulator voltage at the same time >> and doesn't run into an invalid corner case. >> >> We should still make sure, that we always use the correct register >> when controlling the regulator. At least in U-Boot this fixes an >> actual bug where the wrong IO voltage is used. >> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> > > I may have a kind-of obvious request, since we removed those SD_VSEL > very recently from other boards, could you just revert all those patches > and only fill in the SION bit in V2 on all those boards too ? That way, > we fix the LDO5 regulator for everyone who used it before. I thought about that, but as the SD_VSEL signal is controlling the LDO5, I found it more useful/correct to have the sd-vsel-gpios property inside the LDO5 regulator node. Therefore the old usage where sd-vsel-gpios was inside the PMIC node isn't compatible anymore.
Hi Frieder, thanks for the patch. On 23-02-13, Frieder Schrempf wrote: > From: Frieder Schrempf <frieder.schrempf@kontron.de> > > This fixes the LDO5 regulator handling of the pca9450 driver by > taking the status of the SD_VSEL into account to determine which > configuration register is used for the voltage setting. > > Even without this change there is no functional issue, as the code > for switching the voltage in sdhci.c currently switches both, the > VSELECT/SD_VSEL signal and the regulator voltage at the same time > and doesn't run into an invalid corner case. > > We should still make sure, that we always use the correct register > when controlling the regulator. At least in U-Boot this fixes an > actual bug where the wrong IO voltage is used. > > Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> > --- > arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 6 +++--- > arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 6 +++--- > arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 1 + > arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi | 1 + > 4 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts > index 8b16bd68576c..bdcd9cd843c7 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts > @@ -344,7 +344,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -357,7 +357,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -370,7 +370,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts > index a079322a3793..ba2a4491cf31 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts > @@ -321,7 +321,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -334,7 +334,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 The VSELECT pin should be driven by the (u)sdhc core... > >; > }; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > index 5172883717d1..90daaf54e704 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > regulator-name = "NVCC_SD (LDO5)"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3300000>; > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be muxed as GPIO, which is not the case. So I think that u-boot have a bug within the (u)sdhc core. Regards, Marco > }; > }; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi > index 1f8326613ee9..7468a8aa771d 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi > @@ -195,6 +195,7 @@ reg_nvcc_sd: LDO5 { > regulator-name = "NVCC_SD (LDO5)"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3300000>; > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > }; > }; > }; > -- > 2.39.1 > > >
On 13.02.23 17:15, Marco Felsch wrote: > Hi Frieder, > > thanks for the patch. > > On 23-02-13, Frieder Schrempf wrote: >> From: Frieder Schrempf <frieder.schrempf@kontron.de> >> >> This fixes the LDO5 regulator handling of the pca9450 driver by >> taking the status of the SD_VSEL into account to determine which >> configuration register is used for the voltage setting. >> >> Even without this change there is no functional issue, as the code >> for switching the voltage in sdhci.c currently switches both, the >> VSELECT/SD_VSEL signal and the regulator voltage at the same time >> and doesn't run into an invalid corner case. >> >> We should still make sure, that we always use the correct register >> when controlling the regulator. At least in U-Boot this fixes an >> actual bug where the wrong IO voltage is used. >> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> >> --- >> arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 6 +++--- >> arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 6 +++--- >> arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 1 + >> arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi | 1 + >> 4 files changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts >> index 8b16bd68576c..bdcd9cd843c7 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts >> @@ -344,7 +344,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -357,7 +357,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -370,7 +370,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> }; >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts >> index a079322a3793..ba2a4491cf31 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts >> @@ -321,7 +321,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -334,7 +334,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > The VSELECT pin should be driven by the (u)sdhc core... > >> >; >> }; >> }; >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> index 5172883717d1..90daaf54e704 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >> regulator-name = "NVCC_SD (LDO5)"; >> regulator-min-microvolt = <1800000>; >> regulator-max-microvolt = <3300000>; >> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > muxed as GPIO, which is not the case. So I think that u-boot have a bug > within the (u)sdhc core. No, we don't mux the signal as GPIO. We still use the VSLECT mux option, but enable the SION bit, so we can read back the current state of the VSELECT signal via the GPIO.
On 2/13/23 17:15, Marco Felsch wrote: [...] >> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > The VSELECT pin should be driven by the (u)sdhc core... > >> >; >> }; >> }; >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> index 5172883717d1..90daaf54e704 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >> regulator-name = "NVCC_SD (LDO5)"; >> regulator-min-microvolt = <1800000>; >> regulator-max-microvolt = <3300000>; >> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > muxed as GPIO, which is not the case. So I think that u-boot have a bug > within the (u)sdhc core. The trick here is that the VSELECT is operated by the usdhc block as a function pin, but the PMIC driver can read the current state of the VSELECT pin by reading out the GPIO block SR register. Since the IOMUX SION bit is set on the VSELECT pin, the state of the pin is reflected in the GPIO block SR register even if the pin is muxed as function pin.
Hi Marek, Frieder, On 23-02-13, Marek Vasut wrote: > On 2/13/23 17:15, Marco Felsch wrote: > > [...] > > > > @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > > > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > > > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > > > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > > > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > > > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > > > The VSELECT pin should be driven by the (u)sdhc core... > > > > > >; > > > }; > > > }; > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > index 5172883717d1..90daaf54e704 100644 > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > > > regulator-name = "NVCC_SD (LDO5)"; > > > regulator-min-microvolt = <1800000>; > > > regulator-max-microvolt = <3300000>; > > > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > > muxed as GPIO, which is not the case. So I think that u-boot have a bug > > within the (u)sdhc core. > > The trick here is that the VSELECT is operated by the usdhc block as a > function pin, but the PMIC driver can read the current state of the VSELECT > pin by reading out the GPIO block SR register. Since the IOMUX SION bit is > set on the VSELECT pin, the state of the pin is reflected in the GPIO block > SR register even if the pin is muxed as function pin. > Thanks for this explanation :) Why does the regulator driver need to know the current state of this pin? Since the voltage switching requires some cmd's before the actual voltage level switch. So this must be handled within the core. Also after checking the driver, adding the sd-vsel-gpios will request the specified gpio as output-high. Out of curiosity, what's the bug you triggering within U-Boot? Regards, Marco
On 2/13/23 20:56, Marco Felsch wrote: > Hi Marek, Frieder, Hi, > On 23-02-13, Marek Vasut wrote: >> On 2/13/23 17:15, Marco Felsch wrote: >> >> [...] >> >>>> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >>>> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >>>> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >>>> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >>>> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >>>> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >>> >>> The VSELECT pin should be driven by the (u)sdhc core... >>> >>>> >; >>>> }; >>>> }; >>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>> index 5172883717d1..90daaf54e704 100644 >>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >>>> regulator-name = "NVCC_SD (LDO5)"; >>>> regulator-min-microvolt = <1800000>; >>>> regulator-max-microvolt = <3300000>; >>>> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; >>> >>> and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be >>> muxed as GPIO, which is not the case. So I think that u-boot have a bug >>> within the (u)sdhc core. >> >> The trick here is that the VSELECT is operated by the usdhc block as a >> function pin, but the PMIC driver can read the current state of the VSELECT >> pin by reading out the GPIO block SR register. Since the IOMUX SION bit is >> set on the VSELECT pin, the state of the pin is reflected in the GPIO block >> SR register even if the pin is muxed as function pin. >> > > Thanks for this explanation :) Why does the regulator driver need to > know the current state of this pin? Because that regulator has an input pin which selects between two states of that regulator, L and H, and whatever L or H is depends on what is configured into the regulator via I2C. To correctly report the state of the regulator, you have to know the state of that input (selector) pin. > Since the voltage switching requires > some cmd's before the actual voltage level switch. So this must be > handled within the core. > > Also after checking the driver, adding the sd-vsel-gpios will request > the specified gpio as output-high. The GPIO would have to be requested as input, obviously. > Out of curiosity, what's the bug you > triggering within U-Boot? AFAICT the readback of the initial state of the regulator (see paragraph above), which affects Linux all the same.
Hi Frieder, On Mon, Feb 13, 2023 at 1:19 PM Frieder Schrempf <frieder.schrempf@kontron.de> wrote: > No, we don't mux the signal as GPIO. We still use the VSLECT mux option, > but enable the SION bit, so we can read back the current state of the > VSELECT signal via the GPIO. Please include this explanation in the commit log.
On 23-02-13, Marek Vasut wrote: > On 2/13/23 20:56, Marco Felsch wrote: > > Hi Marek, Frieder, > > Hi, > > > On 23-02-13, Marek Vasut wrote: > > > On 2/13/23 17:15, Marco Felsch wrote: > > > > > > [...] > > > > > > > > @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > > > > > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > > > > > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > > > > > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > > > > > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > > > > > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > > > > > > > The VSELECT pin should be driven by the (u)sdhc core... > > > > > > > > > >; > > > > > }; > > > > > }; > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > > > index 5172883717d1..90daaf54e704 100644 > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > > > @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > > > > > regulator-name = "NVCC_SD (LDO5)"; > > > > > regulator-min-microvolt = <1800000>; > > > > > regulator-max-microvolt = <3300000>; > > > > > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > > > > > > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > > > > muxed as GPIO, which is not the case. So I think that u-boot have a bug > > > > within the (u)sdhc core. > > > > > > The trick here is that the VSELECT is operated by the usdhc block as a > > > function pin, but the PMIC driver can read the current state of the VSELECT > > > pin by reading out the GPIO block SR register. Since the IOMUX SION bit is > > > set on the VSELECT pin, the state of the pin is reflected in the GPIO block > > > SR register even if the pin is muxed as function pin. > > > > > > > Thanks for this explanation :) Why does the regulator driver need to > > know the current state of this pin? > > Because that regulator has an input pin which selects between two states of > that regulator, L and H, and whatever L or H is depends on what is > configured into the regulator via I2C. To correctly report the state of the > regulator, you have to know the state of that input (selector) pin. > > > Since the voltage switching requires > > some cmd's before the actual voltage level switch. So this must be > > handled within the core. > > > > Also after checking the driver, adding the sd-vsel-gpios will request > > the specified gpio as output-high. > > The GPIO would have to be requested as input, obviously. But that isn't the case. According the driver comment they just want to make sure that this GPIO is high to ensure that the correct regulator config registers are used. > > Out of curiosity, what's the bug you > > triggering within U-Boot? > > AFAICT the readback of the initial state of the regulator (see paragraph > above), which affects Linux all the same. According the binding the driver should check this and apply the value to the corresponding L/H register but unfortunately this isn't the case yet. Does U-Boot handle this correctly? Regards, Marco
Hi Marco, On 14.02.23 09:10, Marco Felsch wrote: > On 23-02-13, Marek Vasut wrote: >> On 2/13/23 20:56, Marco Felsch wrote: >>> Hi Marek, Frieder, >> >> Hi, >> >>> On 23-02-13, Marek Vasut wrote: >>>> On 2/13/23 17:15, Marco Felsch wrote: >>>> >>>> [...] >>>> >>>>>> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >>>>>> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >>>>>> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >>>>>> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >>>>>> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >>>>>> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >>>>> >>>>> The VSELECT pin should be driven by the (u)sdhc core... >>>>> >>>>>> >; >>>>>> }; >>>>>> }; >>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>>>> index 5172883717d1..90daaf54e704 100644 >>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>>>> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >>>>>> regulator-name = "NVCC_SD (LDO5)"; >>>>>> regulator-min-microvolt = <1800000>; >>>>>> regulator-max-microvolt = <3300000>; >>>>>> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; >>>>> >>>>> and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be >>>>> muxed as GPIO, which is not the case. So I think that u-boot have a bug >>>>> within the (u)sdhc core. >>>> >>>> The trick here is that the VSELECT is operated by the usdhc block as a >>>> function pin, but the PMIC driver can read the current state of the VSELECT >>>> pin by reading out the GPIO block SR register. Since the IOMUX SION bit is >>>> set on the VSELECT pin, the state of the pin is reflected in the GPIO block >>>> SR register even if the pin is muxed as function pin. >>>> >>> >>> Thanks for this explanation :) Why does the regulator driver need to >>> know the current state of this pin? >> >> Because that regulator has an input pin which selects between two states of >> that regulator, L and H, and whatever L or H is depends on what is >> configured into the regulator via I2C. To correctly report the state of the >> regulator, you have to know the state of that input (selector) pin. >> >>> Since the voltage switching requires >>> some cmd's before the actual voltage level switch. So this must be >>> handled within the core. >>> >>> Also after checking the driver, adding the sd-vsel-gpios will request >>> the specified gpio as output-high. >> >> The GPIO would have to be requested as input, obviously. > > But that isn't the case. According the driver comment they just want to > make sure that this GPIO is high to ensure that the correct regulator > config registers are used. It seems like you look at the wrong code. We previously had the sd-vsel-gpios used as you describe, as an output set to a fixed high level to make sure that the SD_VSEL state matches the driver using the H register. This code is reverted in patch 3 and patch 5 implements the sd-vsel-gpios as input as described by Marek. See: https://lore.kernel.org/lkml/20230213155833.1644366-4-frieder@fris.de/ https://lore.kernel.org/lkml/20230213155833.1644366-6-frieder@fris.de/ Sorry, my scripts didn't cc everyone for all patches, which is probably why you missed these changes. > >>> Out of curiosity, what's the bug you >>> triggering within U-Boot? >> >> AFAICT the readback of the initial state of the regulator (see paragraph >> above), which affects Linux all the same. > > According the binding the driver should check this and apply the value > to the corresponding L/H register but unfortunately this isn't the case > yet. Does U-Boot handle this correctly? See above. Thanks Frieder
On 23-02-14, Frieder Schrempf wrote: > Hi Marco, > > On 14.02.23 09:10, Marco Felsch wrote: > > On 23-02-13, Marek Vasut wrote: > >> On 2/13/23 20:56, Marco Felsch wrote: > >>> Hi Marek, Frieder, > >> > >> Hi, > >> > >>> On 23-02-13, Marek Vasut wrote: > >>>> On 2/13/23 17:15, Marco Felsch wrote: > >>>> > >>>> [...] > >>>> > >>>>>> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > >>>>>> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > >>>>>> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > >>>>>> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > >>>>>> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > >>>>>> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >>>>> > >>>>> The VSELECT pin should be driven by the (u)sdhc core... > >>>>> > >>>>>> >; > >>>>>> }; > >>>>>> }; > >>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > >>>>>> index 5172883717d1..90daaf54e704 100644 > >>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > >>>>>> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > >>>>>> regulator-name = "NVCC_SD (LDO5)"; > >>>>>> regulator-min-microvolt = <1800000>; > >>>>>> regulator-max-microvolt = <3300000>; > >>>>>> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > >>>>> > >>>>> and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > >>>>> muxed as GPIO, which is not the case. So I think that u-boot have a bug > >>>>> within the (u)sdhc core. > >>>> > >>>> The trick here is that the VSELECT is operated by the usdhc block as a > >>>> function pin, but the PMIC driver can read the current state of the VSELECT > >>>> pin by reading out the GPIO block SR register. Since the IOMUX SION bit is > >>>> set on the VSELECT pin, the state of the pin is reflected in the GPIO block > >>>> SR register even if the pin is muxed as function pin. > >>>> > >>> > >>> Thanks for this explanation :) Why does the regulator driver need to > >>> know the current state of this pin? > >> > >> Because that regulator has an input pin which selects between two states of > >> that regulator, L and H, and whatever L or H is depends on what is > >> configured into the regulator via I2C. To correctly report the state of the > >> regulator, you have to know the state of that input (selector) pin. > >> > >>> Since the voltage switching requires > >>> some cmd's before the actual voltage level switch. So this must be > >>> handled within the core. > >>> > >>> Also after checking the driver, adding the sd-vsel-gpios will request > >>> the specified gpio as output-high. > >> > >> The GPIO would have to be requested as input, obviously. > > > > But that isn't the case. According the driver comment they just want to > > make sure that this GPIO is high to ensure that the correct regulator > > config registers are used. > > It seems like you look at the wrong code. We previously had the > sd-vsel-gpios used as you describe, as an output set to a fixed high > level to make sure that the SD_VSEL state matches the driver using the H > register. This code is reverted in patch 3 and patch 5 implements the > sd-vsel-gpios as input as described by Marek. See: > > https://lore.kernel.org/lkml/20230213155833.1644366-4-frieder@fris.de/ > https://lore.kernel.org/lkml/20230213155833.1644366-6-frieder@fris.de/ > > Sorry, my scripts didn't cc everyone for all patches, which is probably > why you missed these changes. Ah okay this brings light into the dark :) Thanks for the pointers, just received the DT changes. Regards, Marco
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts index 8b16bd68576c..bdcd9cd843c7 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts @@ -344,7 +344,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -357,7 +357,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -370,7 +370,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; }; diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts index a079322a3793..ba2a4491cf31 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts @@ -321,7 +321,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -334,7 +334,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; }; diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi index 5172883717d1..90daaf54e704 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { regulator-name = "NVCC_SD (LDO5)"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3300000>; + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; }; }; }; diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi index 1f8326613ee9..7468a8aa771d 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi @@ -195,6 +195,7 @@ reg_nvcc_sd: LDO5 { regulator-name = "NVCC_SD (LDO5)"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3300000>; + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; }; }; };