Attention is currently required from: Angel Pons.
Nico Huber would like Angel Pons to review this change.
[DRAFT] Document bitbang SPI thoughts
Change-Id: I2437ad736b6677ad6eefa17a7b2d65d6f489f890
Signed-off-by: Nico Huber <nico.h@gmx.de>
---
A Documentation/bitbang_spi_analysis.md
1 file changed, 150 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/60/55860/1
diff --git a/Documentation/bitbang_spi_analysis.md b/Documentation/bitbang_spi_analysis.md
new file mode 100644
index 0000000..765aeb7
--- /dev/null
+++ b/Documentation/bitbang_spi_analysis.md
@@ -0,0 +1,150 @@
+Analysis of changes to flashrom's `bitbang_spi` driver
+======================================================
+
+* `.half_period` is considered 3 chars long, marked by an `h`.
+
+* Delays incurred by programming or reading a hardware value
+ are 1 char long. So are transmission delays including the
+ time the other endpoint needs to react.
+
+* Assumed is `mode 0`, i.e. `CPOL = 0` and `CPHA = 0`. Changes
+ should happen after a falling edge of `SCK` or `CS#` and
+ sampling after a rising edge of `SCK`.
+
+* `^` denotes a sampling at our end.
+
+Before commit b623f403 (bitbang_spi: Add functions to optimize xfers)
+---------------------------------------------------------------------
+
+ __ h h h h h h h h
+ CS# |_________________________________________
+ ____ ____ ____ ____
+ SCK _______| |____| |____| |____| |_
+
+ MOSI ___11111111112222222222333333333344444444445
+
+ MISO XXXX1111111111222222222233333333334444444444
+ ^ ^ ^ ^
+
+This looks quite balanced actually. Now, what happens if we set
+`.half_period = 0`?
+
+ __
+ CS# |_________________
+ _ _ _ _
+ SCK ____| |_| |_| |_| |_
+
+ MOSI ___11112222333344445
+
+ MISO XXXX1111222233334444
+ ^ ^ ^ ^
+
+Looks ok'ish. Only notice that we sample a little early. It might
+be better to sample after the falling edge of `SCK`, however that
+would make the code incompatible to `.half_period != 0` :-/
+
+With commit b623f403 (bitbang_spi: Add functions to optimize xfers)
+-------------------------------------------------------------------
+
+We explicitly set `SCK = 0` before setting `MOSI` now, which adds
+a tiny delay at the start:
+
+ __ h h h h h h h h
+ CS# |__________________________________________
+ ____ ____ ____ ____
+ SCK ________| |____| |____| |____| |_
+
+ MOSI ____11111111112222222222333333333344444444445
+
+ MISO XXXX11111111111222222222233333333334444444444
+ ^ ^ ^ ^
+
+Nothing to spectacular with `.half_period = 0` either:
+
+ __
+ CS# |__________________
+ _ _ _ _
+ SCK _____| |_| |_| |_| |_
+
+ MOSI ____11112222333344445
+
+ MISO XXXX11111222233334444
+ ^ ^ ^ ^
+
+With commit 455a6fc8 (bitbang_spi: Add half-duplex optimizations)
+-----------------------------------------------------------------
+
+We assume half-duplex from now on. This removes a sampling delay
+per bit on our end during the first, writing phase, and a program-
+ming delay per bit during the second, read phase.
+
+We still program `MOSI = 0` at the start of every byte *read*,
+though. Don't know why. It incurs a programming delay per byte.
+We'll mark this with `o` for odd. We'll also assume bytes are
+only 2 bits long, to not make the diagrams explode.
+
+ __ h h h h h h h h
+ CS# |_______________________________________
+ ___ ___ ____ ____
+ SCK ________| |____| |____| |___| |_
+
+ MOSI ____111111111222222222____________________
+
+ MISO XXXXXXXXXXXXXXXXXXXXXXX3333333333444444444
+ ^ ^
+
+Note that during the write phase, the clock-high periods are
+shorter now, and during the read phase, the clock-lock periods
+are shorter. Now, once again, let's remove the `.half_period`
+delays (vim makes this awesomely easy btw. ^^).
+
+ __
+ CS# |_______________
+ _ _
+ SCK _____||_||_| || ||
+
+ MOSI ____111222________
+
+ MISO XXXXXXXXXXX3333444
+ ^ ^
+
+This looks pretty tense. But remember: everyone is supposed
+to sample after a rising edge of `SCK`. Which is right in the
+center of our `MOSI` output. With `MISO`, however, things
+look bad. This is assuming programming, sampling and a trans-
+mission round-trip all take the same time. *If* the round-trip
+is not longer, we should still be safe.
+
+Making use of 455a6fc8's optimizations
+--------------------------------------
+
+Now what happens if we pack setting `SCK = 0` with setting
+`MOSI` and setting `SCK = 1` with sampling `MISO`?
+
+ __ h h h h h h h h
+ CS# |___________________________________
+ ___ ___ ___ ___
+ SCK ________| |___| |___| |___| |_
+
+ MOSI ____1111111122222222__________________
+
+ MISO XXXXXXXXXXXXXXXXXXXXXX3333333344444444
+ ^ ^
+
+A nice picture once more, but what happens if we ditch
+`.half_period`?
+
+ __
+ CS# |___________
+
+ SCK _____||||||||_
+
+ MOSI ____1122______
+
+ MISO XXXXXXXXXX3344
+ ^ ^
+
+We'd definitely sample very early. Could it work? I don't know.
+This would have to be tested. It even seems possible that raising
+`.half_period` above 0 together with this optimization might
+increase the speed and reliability.
To view, visit change 55860. To unsubscribe, or for help writing mail filters, visit settings.