From patchwork Wed Apr 12 20:36:43 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Golle X-Patchwork-Id: 1768270 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4PxZJX0Gb0z1yZk for ; Thu, 13 Apr 2023 06:37:14 +1000 (AEST) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CD80D85DCF; Wed, 12 Apr 2023 22:37:01 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 6E24585FB2; Wed, 12 Apr 2023 22:36:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: from fudo.makrotopia.org (fudo.makrotopia.org [IPv6:2a07:2ec0:3002::71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 55A238598A for ; Wed, 12 Apr 2023 22:36:56 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=daniel@makrotopia.org Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.96) (envelope-from ) id 1pmhD3-0001QX-0e; Wed, 12 Apr 2023 22:36:53 +0200 Date: Wed, 12 Apr 2023 21:36:43 +0100 From: Daniel Golle To: u-boot@lists.denx.de, Sam Shih , GSS_MTK_Uboot_upstream , Chunfeng Yun , Weijie Gao , Ryder Lee , Frank Wunderlich Cc: Steven Liu =?utf-8?b?KOWKieS6uuixqik=?= , John Crispin Subject: [PATCH] pinctrl: mediatek: set R1/R0 in case pullen/pullsel succeeded Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean Commit dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and related functions") changed the logic deciding to set R0 and R1 registers for V1 devices. Before: /* Also set PUPD/R0/R1 if the pin has them */ err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PUPD, !pullup); if (err != -EINVAL) { mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R0, r0); mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R1, r1); } After: /* try pupd_r1_r0 if pullen_pullsel return error */ err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup, val); if (err) return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable, pullup, val); Tracing mtk_pinconf_bias_set_pullen_pullsel shows that the function always either returns 0 in case of success or -EINVAL in case any error has occurred. Hence the logic responsible of the decision to program R0 and R1 has been inverted. This leads to problems on BananaPi R2 (MT7623N) when booting from SDMMC, it turns out accessing eMMC no longer works since U-Boot 2022.07: MT7623> mmc dev 0 Card did not respond to voltage select! : -110 The problem wasn't detected for a long time as both eMMC and SDMMC work fine if they are used to boot from, and hence R0 and R1 were already setup by the bootrom and/or preloader. Fix the logic to restore the originally intended and correct behavior and also change the descriptive comment accordingly. Fixes: dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and related functions") Signed-off-by: Daniel Golle Tested-By: Frank Wunderlich --- drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c index 4ae328699e2..23d759aa2d8 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c @@ -319,10 +319,10 @@ int mtk_pinconf_bias_set_v1(struct udevice *dev, u32 pin, bool disable, { int err; - /* try pupd_r1_r0 if pullen_pullsel return error */ + /* set pupd_r1_r0 if pullen_pullsel succeeded */ err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup, val); - if (err) + if (!err) return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable, pullup, val);