Attention is currently required from: Angel Pons. Hello Angel Pons,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/flashrom/+/55860
to review the following change.
Change subject: [DRAFT] Document bitbang SPI thoughts ......................................................................
[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.