Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C8EAC05027 for ; Tue, 14 Feb 2023 08:11:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231924AbjBNILR (ORCPT ); Tue, 14 Feb 2023 03:11:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231913AbjBNILK (ORCPT ); Tue, 14 Feb 2023 03:11:10 -0500 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 AC015233C8 for ; Tue, 14 Feb 2023 00:10:52 -0800 (PST) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRqOg-0005Z0-NR; Tue, 14 Feb 2023 09:10:42 +0100 Received: from mfe by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1pRqOf-0004c3-SU; Tue, 14 Feb 2023 09:10:41 +0100 Date: Tue, 14 Feb 2023 09:10:41 +0100 From: Marco Felsch To: Marek Vasut Cc: Frieder Schrempf , devicetree@vger.kernel.org, Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Rob Herring , Sascha Hauer , Shawn Guo , Frieder Schrempf , Oleksij Rempel , Krzysztof Kozlowski , NXP Linux Team , Pengutronix Kernel Team , Heiko Thiery , Fabio Estevam Subject: Re: [PATCH 6/6] arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal Message-ID: <20230214081041.6rys3eydmakim2yy@pengutronix.de> References: <20230213155833.1644366-1-frieder@fris.de> <20230213155833.1644366-7-frieder@fris.de> <20230213161548.ucaqpza65byyqvfo@pengutronix.de> <20230213195617.xndagbarc3k5kegr@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: mfe@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 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