linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Anderson <dianders@chromium.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	swboyd@chromium.org, Douglas Anderson <dianders@chromium.org>,
	Akash Asthana <akashast@codeaurora.org>,
	Andy Gross <agross@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor
Date: Thu, 18 Feb 2021 14:55:09 -0800	[thread overview]
Message-ID: <20210218145456.1.I1da01a075dd86e005152f993b2d5d82dd9686238@changeid> (raw)

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.

Fixes: cfbb97fde694 ("arm64: dts: qcom: Switch sc7180-trogdor to control SPI CS via GPIO")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 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 07c8b2c926c0..e6c58d12dacd 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -768,17 +768,17 @@ &sdhc_2 {
 };
 
 &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 {
@@ -1339,6 +1339,27 @@ pinconf {
 		};
 	};
 
+	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.0.617.g56c4b15f3c-goog


             reply	other threads:[~2021-02-18 22:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18 22:55 Douglas Anderson [this message]
2021-02-19  0:55 ` [PATCH] arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor Doug Anderson
2021-02-22 20:12 ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210218145456.1.I1da01a075dd86e005152f993b2d5d82dd9686238@changeid \
    --to=dianders@chromium.org \
    --cc=agross@kernel.org \
    --cc=akashast@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).