lkml.org 
[lkml]   [2021]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor
From
Date
Quoting Douglas Anderson (2021-02-18 14:55:09)
> 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>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

\
 
 \ /
  Last update: 2021-02-22 21:16    [W:0.035 / U:29.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site