Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4664993pxj; Wed, 12 May 2021 10:22:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0meVV1fGaFIkSH7xRb4yxylqdk6RkUNOzik4ofRT3BhRPO29qLEwL+yL1xi8yiFpSKn+w X-Received: by 2002:a4a:b186:: with SMTP id c6mr11732052ooo.28.1620840162294; Wed, 12 May 2021 10:22:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620840162; cv=none; d=google.com; s=arc-20160816; b=OD0jVmjecvQxAT3j4Kv8uvGWMmiWK6lWlvmAV6LEWatKNPvMr0UzftHz6Z8s+bZtAR 9/UhQlDIIMZDPwWbbhMJOOJVNJ9i43guqgKAGjTLzjA1glfHisQJz3IvH1aeAYro7CTy lp0Nc8cFWezcVQklQKnXP9fu21tti/X2Qd60XnEOeZ769AvrLmucbNAiPs7vtpEQBe2U 7QYkMCpJU2cFtWGql6MLZMwABmvOQ8cTsgXizsBA4Qv/rtHA8DU01lmmD93l89o6qXBH cwPkM+plfxq5X1U4pAFKBt57QBaG7hP1bmzrWEDjCaO8MuQU+VUs3a/VL3xQo9vqE9zs UJxA== 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:message-id:date:subject:cc:to :from:dkim-signature; bh=AgkObdnA+QA2ou0c2+zfOTYsjWfIMY7hyK9NBvFSRak=; b=WD6f6pjk6R9tssjokv7LPg01RbgMb2WtdG1wniIvTgIxCfQYHF3i2WmRch9+4zj7D+ qX9LsEhpToq5UqLhP6U7YTUm3eufiY9SlMnrX7l8slP8XiQobgLkWovOb8SLkagWarxb jeN80EduGrqzZaUAxzr8fJ6VYz5k96fbhhE218YpamsEWYhF+bXq1lD6i53HhtqVURXH CRgnQ1uM6KxrJ7wCMmMz7YCNAqHKGzYcEVI3zkl3ENeqa3QllAN26nv9t2uxRhfyTknf q0h1dqbQXKGdH/mYFKRkWPUK1eKEbG7aieWMHZHgEBcQDRQacsi0DffQy+RBUsm9zMZ8 ayMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Foq/1brj"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p24si487935otk.34.2021.05.12.10.22.27; Wed, 12 May 2021 10:22: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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Foq/1brj"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343833AbhELRPc (ORCPT + 99 others); Wed, 12 May 2021 13:15:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:52040 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237212AbhELQDx (ORCPT ); Wed, 12 May 2021 12:03:53 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4A9BF61CE2; Wed, 12 May 2021 15:33:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620833619; bh=FRuAeRkFMpnn9EPkbE2+X2ot5ARnDbX+6RJ/CaSKVDM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Foq/1brjmcoFMSsuLfCZ+QUpiXf9LQp42NSsNJlxPrRGyoEGjb1LrSnFDSE67uhAu ILwwj3G9QG2LKPVLg8S2zgE+5vaUveiTNh28E7Fd6DUW88YQPLkX6i4HmYKHrRYLzN C/sAY0LdfV2EO7ATkL9X+5F1jX74qAD4I65utTiw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephen Boyd , Douglas Anderson , Bjorn Andersson , Sasha Levin Subject: [PATCH 5.11 178/601] arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor Date: Wed, 12 May 2021 16:44:15 +0200 Message-Id: <20210512144833.703311663@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210512144827.811958675@linuxfoundation.org> References: <20210512144827.811958675@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Douglas Anderson [ Upstream commit e440e30e26dd6b0424002ad0ddcbbcea783efd85 ] At boot time the following happens: 1. Device core gets ready to probe our SPI driver. 2. Device core applies SPI controller's "default" pinctrl. 3. Device core calls the SPI driver's probe() function which will eventually setup the chip select GPIO as "unasserted". Thinking about the above, we can find: a) For SPI devices that the BIOS inits (Cr50 and EC), the BIOS would have had them configured as "GENI" pins and not as "GPIO" pins. b) It turns out that our BIOS also happens to init these pins as "output" (even though it doesn't need to since they're not muxed as GPIO) but leaves them at the default state of "low". c) As soon as we apply the "default" chip select it'll switch the function to GPIO and stop driving the chip select high (which is how "GENI" was driving it) and start driving it low. d) As of commit 9378f46040be ("UPSTREAM: spi: spi-geni-qcom: Use the new method of gpio CS control"), when the SPI core inits things it inits the GPIO to be "deasserted". Prior to that commit the GPIO was left untouched until first use. e) When the first transaction happens we'll assert the chip select and then deassert it after done. So before the commit to change us to use gpio descriptors we used to have a _really long_ assertion of chip select before our first transaction (because it got pulled down and then the first "assert" was a no-op). That wasn't great but (apparently) didn't cause any real harm. After the commit to change us to use gpio descriptors we end up glitching the chip select line during probe. It would go low and then high with no data transferred. The other side ought to be robust against this, but it certainly could cause some confusion. It's known to at least cause an error message on the EC console and it's believed that, under certain timing conditions, it could be getting the EC into a confused state causing the EC driver to fail to probe. Let's fix things to avoid the glitch. We'll add an extra pinctrl entry that sets the value of the pin to output high (CS deasserted) before doing anything else. We'll do this in its own pinctrl node that comes before the normal pinctrl entries to ensure that the order is correct and that this gets applied before the mux change. This change is in the trogdor board file rather than in the SoC dtsi file because chip select polarity can be different depending on what's hooked up and it doesn't feel worth it to spam the SoC dtsi file with both options. The board file would need to pick the right one anyway. Reviewed-by: Stephen Boyd Fixes: cfbb97fde694 ("arm64: dts: qcom: Switch sc7180-trogdor to control SPI CS via GPIO") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20210218145456.1.I1da01a075dd86e005152f993b2d5d82dd9686238@changeid Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin --- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 27 +++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi index 5c650b902c10..472f598cd726 100644 --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi @@ -838,17 +838,17 @@ hp_i2c: &i2c9 { }; &spi0 { - pinctrl-0 = <&qup_spi0_cs_gpio>; + pinctrl-0 = <&qup_spi0_cs_gpio_init_high>, <&qup_spi0_cs_gpio>; cs-gpios = <&tlmm 37 GPIO_ACTIVE_LOW>; }; &spi6 { - pinctrl-0 = <&qup_spi6_cs_gpio>; + pinctrl-0 = <&qup_spi6_cs_gpio_init_high>, <&qup_spi6_cs_gpio>; cs-gpios = <&tlmm 62 GPIO_ACTIVE_LOW>; }; ap_spi_fp: &spi10 { - pinctrl-0 = <&qup_spi10_cs_gpio>; + pinctrl-0 = <&qup_spi10_cs_gpio_init_high>, <&qup_spi10_cs_gpio>; cs-gpios = <&tlmm 89 GPIO_ACTIVE_LOW>; cros_ec_fp: ec@0 { @@ -1402,6 +1402,27 @@ ap_spi_fp: &spi10 { }; }; + qup_spi0_cs_gpio_init_high: qup-spi0-cs-gpio-init-high { + pinconf { + pins = "gpio37"; + output-high; + }; + }; + + qup_spi6_cs_gpio_init_high: qup-spi6-cs-gpio-init-high { + pinconf { + pins = "gpio62"; + output-high; + }; + }; + + qup_spi10_cs_gpio_init_high: qup-spi10-cs-gpio-init-high { + pinconf { + pins = "gpio89"; + output-high; + }; + }; + qup_uart3_sleep: qup-uart3-sleep { pinmux { pins = "gpio38", "gpio39", -- 2.30.2